Re: partially encrypted filesystem

From: Jörn Engel
Date: Thu Dec 04 2003 - 13:47:03 EST


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