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

the grugq
2004-02-07T11:05:32Z

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.