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

[Hans Reiser <reiser@namesys.com>]

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