I would like to decrypt certain data into a file, use the file, and when done, "wipe" the file using something like "wipe" or "shred".

However, my file system is "ext3", and I am told that following a "shred", journal entries could still exist containing sensitive data.

Also, I don't have any free partitions to use for doing this, which would solve the problem easily.

So, I am wondering if the following would work:

1. Create, say, a 20 mb file in the ext3 partition.
2. using mkfs, create a "ext2" type filesystem (with no journalling) in that file.
3. Mount the file as loop device.
4. Create files containing the decrypted, sensitive data in that mounted filesystem, run "shred", and delete the files.

If I do this, could there still be any sensitive data hanging around in the ext3 journals (or anywhere else)?

Thanks, if anyone can shed light on this.

David Geller

Could you use a ramdisk?
Here's someone who did it for the same reason:
http://www.vanemery.com/Linux/Ramdisk/ramdisk.html

You got me interested. The ramdisks don't take up any space until you use them, so you can specify them to be big.
And you can change the size without rebooting.
http://www.linuxfocus.org/English/No...rticle124.html
Of course you need to have 20MB ram spare - surely?

Seems you can only change the default size without rebooting if your ramdisk support is a module of the kernel, not if it's compiled in (like mine).

try using tmpfs, it's better suited for what you're trying to do, however make sure you write over all 20 megs or however large you make it so it doesnt get stuck in memory once you're done. On another note though, I don't believe the ext3 journal stores anything other than inode location, filename and file size.

That's really good stuff.

You're right. By default, ext3 only stores meta-data in this journal and you may change/revert this. See tune2fs(8)

Ext3 can be set to store the whole file in the journal, but the default is storing just inodes and meta-data.

But the problem with ext3 (and any modern filesystem) is not the journal, but the fact that it normally doesn't write new data in the same sectors as previous stuff. E. g. if you 'overwrite' a file, the file system might in fact just store the new data on a different physical location on the disk and update the inodes with the old data still on disk and recoverable, given enough time.

I'm not 100% sure, but it isn't the case with ext3 which is said to be only ext2 + a journal. It applies to log structured filesystems and the like.