Messages in this thread | | | Date | Sat, 07 Feb 2004 11:02:55 +0000 | From | the grugq <> | Subject | Re: PATCH - ext2fs privacy (i.e. secure deletion) patch |
| |
Yes, the allocation of the inode and data blocks should be randomized for security, but that would lead to performance impacts. Implementing that should definately be a compile time option.
I would advocate erasing all meta-data on a file, and also erasing the data. The end-user can be responsible for erasing the data, they can access it with write(), but they can't access the meta-data (not without directly accessing the file system). Thats why I'm putting these patches forward. The file system should be responsible for removing meta-data when a file is deleted. This secure deletion doesn't have to incorporate data block erasure (although my implemenation does).
Your suggestion would certainly work, but I think the performance impact of using random inodes and data blocks would dissuade many from having it enabled by default. Simple secure deletion of the data and meta-data would have a lower impact, and be more likely to be used on more file systems.
peace,
--gq
> > This is how to implement secure deletion cryptographically: > > - Each time a file is created, choose a random number. > > - Encrypt the number with your filesystem key and store the > encrypted version in the inode. > > - The number is used for encrypting that file. > > Secure deletion is then a matter of securely deleting the inode. > The file data does not have to be overwritten. > > This is secure against many attacks that "secure deletion" by > overwriting is weak against. This includes electron microscopes > looking at the data, and UK law. (The police can demand your > filesystem key, but nobody knows the random number that belonged to a > new-deleted inode). > > There is a chance the electron microscope may recover the number from > the securely deleted inode. That is the weakness of this system, > therefore the inode data should be very thoroughly erased or itself > subject to careful cryptographic hding.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |