Comment 126 for bug 344878

Revision history for this message
mhalcrow (mhalcrow) wrote :

Hi, original designer/author of eCryptfs chiming in. Sorry for the mess with file name lengths, but because of technical constraints in the kernel file system stack and security concerns, I went with the design I did.

Good news is, I fixed this issue for file-based encryption by designing it (sort of) right in file system native encryption. That's currently available in ext4 for kernels 4.1 and later. We're working to switch from eCryptfs to ext4 encryption for Ubuntu 17.10.

https://github.com/google/fscrypt/issues/24

We've released a really great user space utility to help you do pretty much everything you can do with eCryptfs today:

https://github.com/google/fscrypt

https://launchpad.net/~ubuntu-security/+archive/ubuntu/ubuntu-security-staging/+build/13255257

Prior to Ubuntu 17.10, you'll be in "early adopter" territory with ext4 encryption on Ubuntu.

Note that I did make a security tradeoff with the current version of file name encryption in ext4 for the sake of giving you (1) the full 255 characters and (2) decent performance. If the plaintext prefixes for two file names in the same directory collide, then the ciphertext prefixes will also collide. I asked Alex Cope and Eric Biggers to try to fix that by implementing a new encryption mode that they proposed upstream, but getting new encryption modes upstream isn't necessarily a trivial prospect. No real crypto review/comments so far.

https://www.spinics.net/lists/linux-crypto/msg22416.html

Note that Android is carrying the HEH patches and is using that mode for file name encryption. Hopefully we'll be able to get that upstream at some point.