Re: PATCH - ext2fs privacy (i.e. secure deletion) patch

[the grugq <grugq@hcunix.net>]

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.