On Thu, Mar 25, 2004 at 12:18:08AM +0100, Enrique Perez-Terron wrote: > So, even a fairly cheap and quick encryption system combined with a > "secure delete" facility makes it many orders of magnitude more > expensive to recover any information from the disk. While it is hardly > the first priority, there might still be many customers that will one > day be willing to pay for this.
i really like the idea of a per file key in the inode. the fs could wipe the key field itself, using the gutmann method, without too much trouble (like wiping the entire file from within the kernel; that could be gigs and take hours). could this be implimented using plugins? also, it was mentioned that reiserfs doesn't reserve space. so all structures (except the superblock and journal, of course) are dynamic and regular files can overwrite old nodes? if so, then wipe could use a regular file to wipe free space fairly effectively. if not, maybe i could use the reiserfsprogs libs to figure out what blocks are free (before it's mounted of course). btw, anyone know what the block coherancy is in 2.6? if i write to a blkdev, then mount it, will the fs driver see the writes? i know if the fs writes to the blkdev, reading the blkdev from userspace can return stale cache. too bad you can't do something like umount; bsync; (now safely read/write the blkdev). -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE
