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

[the grugq]

> 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.


peace,

--gq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/