Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a new eCryptfs user and I have a very basic question that I wasn't able to find anywhere. I am interested in using eCryptfs via my Synology NAS that uses Linux.

While trying to encrypt my folder (EXT4) via Synology's encryption app (eCryptfs) I encounter errors that state that my filename length can not exceed 45 characters in length (so, no encryption).

If the limit really is 45 characters, eCryptfs may not be a usable tool for most.

What is the maximum allowed filename size when encrypting files and folders with eCryptfs? Is Linux 255 characters?

share|improve this question
2  
Imho the way ecryptfs does encrypt filenames is plain ridiculous. First it gives away more than 20 bytes by prepending a fixed string "ECRYPTFS_FNEK_ENCRYPTED." to each filename. Then it does prepend way too many random bytes to make identical names look different. EncFS does that in a much more efficient way. – user108611 Mar 30 '15 at 20:13

Full disclosure: I am one of the authors and the current maintainer of the eCryptfs userspace utilities.

Great question!

Linux has a maximum filename length of 255 characters for most filesystems (including EXT4), and a maximum path of 4096 characters.

eCryptfs is a layered filesystem. It stacks on top of another filesystem such as EXT4, which is actually used to write data to the disk. eCryptfs always encrypts file contents, but it can optionally encrypt (obscure) filenames (or not).

If filenames are not encrypted, then you can safely write filenames of up to 255 characters and encrypt their contents, as the filenames written to the lower filesystem will simply match. While an attacker would not be able to read the contents of index.html or budget.xls, they would know what file names exist. That may (or may not) leak sensitive information depending on your use case.

If filenames are encrypted, things get a little more complicated. eCryptfs prepends a bit of data on the front of the encrypted filename, such that it can identify encrypted filenames definitively. Also, the encryption itself involves "padding" the filename.

For instance, I have an encrypted file, ~/.bashrc. This filename is encrypted using my key to:

/home/kirkland/.Private/ECRYPTFS_FNEK_ENCRYPTED.dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

Clearly, that 7 character filename now requires more than 7 characters to be encrypted. Empirically, we have found that character filenames longer than 143 characters start requiring >255 characters to encrypt. So we (as eCryptfs upstream developers) typically recommend you limit your filenames to ~140 characters.

Now, all that said, the Synology NAS is a commercial product that embeds and uses eCryptfs and Linux to encrypt and secure data on the device. We (the upstream developers of eCryptfs) have nothing to do with Synology or their products, though we're generally happy to see eCryptfs used in the wild. It seems to me that their recommendation of 45 characters is either a typographical error (from our 140 character recommendation), or simply a far more conservative estimate.

share|improve this answer
    
I would really love to see, FUSE overlay filesystem that resolves on it's own "too long filenames" and rest just proxy 1:1 with underlaying filesystem. Such FUSE fs would be usefull for different filesystems (ecryptfs, EncFS), while for currently supported filenames would change nothing. And again, would be optional. - My wish: unix.stackexchange.com/q/283149/9689 – Grzegorz Wierzowiecki May 14 at 15:15
    
This answer is not entirely correct. The max size of a filename is 255 Bytes or C/C++ char types. But the max characters in a filename vary. When using UTF-8 which is the default for most systems, the filename can be between 63-255 characters (aka Code Points), if using UTF-16, 63-127. Its important to note, that 1 character can be one or more bytes in storage space and depends on the code set that the user of the system is using. – Rahly May 30 at 19:31

This thread is very interesting because I was wondering the exact same thing. I can live with having to rename 20 files out of 50 000 if the filenames need to be 140 characters or less, but 45 or less isn't feasible (in my situation) because it would require me to rename too many files.

I asked the exact same question directly to Synology (even pointing them to the present article), and their answer was interesting: "The encrypted share's file name limit is 143 bytes. It can be up to 140 pure Latin character or 45 CJK(Chinese, Japanese, and Korean) characters."

Following this answer I did more testing myself, testing with files that were 45, 46, 140, 143 and 144 characters. My tests show that files up to 143 characters (not bytes, contrary to what Synology told me) will be encrypted, but files with 144 characters will PREVENT a folder to be encrypted. However, the ERROR MESSAGE that I get from my NAS is that the filename needs to be less than 45 characters (whereas the reality is that it should be less than 144 characters).

I did not do tests with CJK characters... But, to anyone reading this, it seems that you are fine until 143 characters, despite what the system tells you.

share|improve this answer

I would like to clarify, that linux has a 255 bytes limit per filename, not 255 characters. This is a significant difference and if you use e.g. UTF-8 encoding, you may end up with filenames of 100 characters max.

share|improve this answer
    
63 is the max if every character uses the max encoding of 4 bytes per code point. This is the same for any of the UTF schemas (UTF-16 and UTF-32) – Rahly May 30 at 19:35
    
@Rahly That may eventually change, though. Before the maximum valid Unicode code point was reduced to U+10FFFF to meet the limitations of UCS-2 (basically UTF-16 without surrogate pairs), UTF-8 could require up to 6 bytes to represent a 32-bit code point because of how it encodes "start of character" and "continuation of character" to ensure that parser synchronization can be re-acquired no matter where you start parsing within a byte stream. It's always a possibility that they'll eventually decide to reverse that decision because they're running out of unassigned code points. – ssokolow Jun 1 at 19:01
    
But highly unlikely, unless they start adding characters like mad. As of U8.0, only 120k are assigned. They added ~8k characters in this iteration. If they keep it up, it'll needed expanding at version ~106. – Rahly Jun 7 at 16:00

The filename length of ecrypt was only an issue for me in that I needed a particular subtree of my home directory to support long filenames, and eventually I realised I could simply create a filesystem inside a file and mount that:

dd if=/dev/zero of=/home/me/.some.img bs=1024 count=1024
mkfs.ext3 /home/me/.some.img
chmod 777 /home/me/longfilenames
sudo mount /home/me/.some.img /home/me/longfilenames

There are probably all sorts of efficiency issues with this, but it's sufficient for my case where the files are just test results periodically created for my own local purposes.

My colleagues have put their image in /tmp - the test data isn't particularly confidential: we mainly want to secure our source code, not our test results.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.