[lkml]   [2004]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH - ext2fs privacy (i.e. secure deletion) patch

> What do you mean?
> I haven't mentioned randomising block allocations at all.
> The random number is an encryption key, private to the inode, used to
> encrypt the data blocks. The blocks are allocated efficiently as usual.

I didn't understand your proposal. nm.

As I now understand, you are proposing a file system which has per file
encryption where the key is stored in the inode. The inode is then the
only location with senstive data which needs to be removed.

What about directory files? That is, how would you propose handling the
directory entries of deleted files?

Also, this proposal seems to me more related to how to implement an
encrypted file system, than how to implement secure deletion on existing
file systems.

> My suggestion would be much more efficient than yours: for every file
> created and deleted, you do twice the I/O I do.

Sorry, per file encryption is more efficient than deffered block writes
after deletion? What you are proposing is unrelated to secure deletion.
Its an encrypted file system implementation. Comparing efficiency
between secure deletion on ext2, for example, and encrypted files on
some unimplemented file system doesn't make sense.

Now, given that my comments were on what I thought you were proposing
(randomly allocating inodes and blocks to prevent an analyst being able
to piece a file back toghether via guess work) not what you actually
were proposing (an encrypted file system implementation), ignore the
previous email.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.078 / U:11.804 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site