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

Hans Reiser
2004-02-07T16:50:42Z

the grugq wrote:

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

It will be easy to code on reiser4 which has encryption being built into it.

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

Oh yes. Way so.

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