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

[Hans Reiser]

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

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