Re: partially encrypted filesystem

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Thu, 4 December 2003 18:20:05 +0000, Phillip Lougher wrote:
> Jörn Engel wrote:
> >
> >So - as sick as it sounds - jffs2 may actually be the fs of choice
> >when doing encryption, even though working on a hard drive and not
> >flash.  Cool. :)
> >
> 
> Considering that Jffs2 is the only writeable compressed filesystem, yes. 
>  What should be borne in mind is compressed filesystems never expect 
> the data after compression to be bigger than the original data.  In the 
> case where the compressed data is bigger, the original data is used 
> instead, which is hardy ideal for an encrypted filesystem, and so more 
> than a direct substitution of compression function for encrypt function 
> is needed - this is of course only relevant if the encryption algorithm 
> used could return more data...

Correct.  But this requirement can easily be weakened a enough for
encryption to work.  A couple ALIGN(..., encrypt_blocksize) at two or
three places should do the trick.

> >Depends on how much security you really care about.  If you really
> >don't mind the pain involved, some metadata should explicitly *not* be
> >encrypted, to avoid known plaintext attacks.  To a serious attacker,
> >this could be a death stroke for ext[23] over cryptoloop, actually.
> 
> You're assuming the metadata (inodes, indexes and directory entries), 
> are encrypted with the same key, and therefore decrypting the directory 
> data using plaintext attacks will give the attacker the key to the 
> entire metadata?  There is nothing preventing the directory data being 
> encrypted separately with a different key, and therefore a plaintext 
> attack would get nothing more than the directory information.

True, although that barely makes a difference.  In either case you
have to seperate known-plaintext data from the rest and either not
encrypt it or use a different key.  The hard part is seperating the
data.

> As you say, you highlight a drawback with cryptoloop and cloop, because 
> they cannot distinquish between different types of data.  This sort of 
> thing should always be done at the fs level rather than the block level...

If it is done, yes.  "fsck it, who cares" may also be a valid design.

> >In real life, though, the humans are usually the weakest link, so this
> >doesn't matter anyway.
> 
> Hmmm, why not give give up completely then?

Because it is fun doing so or someone pays for it.  And - more to the
point - the humans should be the weakest link, that is bad enough
already.  No reason to make/leave things worse.

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham