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. ** Bug watch added: github.com/google/fscrypt/issues #24 https://github.com/google/fscrypt/issues/24 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/344878 Title: file name too long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) Status in eCryptfs: Fix Released Status in ecryptfs-utils package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in ecryptfs-utils source package in Natty: Won't Fix Status in linux source package in Natty: Won't Fix Status in ecryptfs-utils source package in Oneiric: Won't Fix Status in linux source package in Oneiric: Won't Fix Status in ecryptfs-utils source package in Precise: Invalid Status in linux source package in Precise: Fix Released Bug description: === IMPORTANT: eCryptfs can only store filenames of up to 143 characters when filename encryption is enabled. The remaining 112 characters are used for storing metadata such as the encrypted filename prefix, the signature of the filename encryption key, and an identifier for the cipher used, as well as random bytes to make /foo/file and /bar/file encrypt to different ciphertext and padding bytes to achieve proper cipher block size alignment. This bug is considered 'fixed' by the upstream maintainers. The eCryptfs kernel error message has been reduced to a debug level log message and eCryptfs now correctly reports its maximum supported filename length through the statfs() syscall. This is all that can be done without implementing a completely new encrypted filename design. A design that allows 255 character filenames without introducing other design limitations has not been identified and no one is currently working to come up with such a design. Please do not add comments or create new bugs saying that mv reports 'File name too long' or that you can't create a long filename in your eCryptfs mounts. It is an unfortunate design limitation that cannot be avoided at this time. Please do create new bugs when an application generates filenames that are too long to be stored in an eCryptfs mount. The application may be able to use the statfs() syscall to check the filename length limits of eCryptfs. Note that this does not include something like a torrent or ftp client trying to download a file with a long filename. The application is not generating the filename in those cases, it is just downloading the file that the user told it to download. === When trying to create a new file with a relatively long filename (f. ex. dfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqb.txt) I get an error: file name to long, when in fact the file name is not to long, but the encrypted name created for this file is to long, so, the file was not created. this is no problem when I try to create a file, but when I'm copying a lot of files to my home folder I get some: filename to long error's and it's hard to fix (first locate the file, create shorter name, move again) so, maybe you could create a check for to long filenames? I'm using ext4 here... mv dfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqb.txt /home/jens/ mv: cannot stat `/home/jens/dfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqbdfkmqsdgjfmqsldjfmlsqkjlqkdmfsmgjlqlskdqshgpoizehmlqkbgmlqbgmqb.txt': File name too long libecryptfs0: Installed: 71-0ubuntu2 Candidate: 71-0ubuntu2 Version table: *** 71-0ubuntu2 0 500 http://be.archive.ubuntu.com jaunty/main Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/344878/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
