Messages in this thread | | | Date | Thu, 4 Dec 2003 19:40:34 +0100 | From | Jörn Engel <> | Subject | Re: partially encrypted filesystem |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |