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

the grugq
2004-02-07T11:49:09Z

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