lkml.org 
[lkml]   [2004]   [Feb]   [7]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 07 Feb 2004 11:02:55 +0000
Fromthe grugq <>
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:00    [from the cache]
©2003-2008