65

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?

Improve this question
1
  • 6
    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
    Commented Mar 30, 2015 at 20:13

4 Answers 4

Reset to default
97

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.

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.

Improve this answer
11
  • 24
    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
    Commented May 30, 2016 at 19:31
  • 2
    Suggestion to developer: Split encrypted names across subdirectories that are hidden from the end user to get the necessary length, potentially even exceeding the linux max name length limit if an external filesystem needs it. A single file or directory becomes "ENCRYPTFS-01-OF-04[.....]/ENCRYPTFS-02-OF-04[.....]/ENCRYPTFS-03-OF-04[.....]/ENCRYPTFS-04-OF-04[.....]" -- Linux btrfs, ext1-4, and others have no max defined directory depth so the filesystem can handle expanding file and dir names across multiple unexposed subdirectories like this.
    – Dale Mahalko
    Commented Dec 9, 2016 at 23:52
  • 2
    My suggestion would have been to store whatever metadata you're storing in the xattrs, instead of in the filename. :|
    – Hakanai
    Commented Sep 14, 2018 at 1:07
  • 1
    You say eCryptfs "can optionally encrypt (obscure) filenames (or not)." How do I disable file name encryption so I can get my full 255-char file names back instead of being limited to 143 chars? I believe the way I got eCryptfs installed, by the way, was by checking the box or whatever for "Encrypted home directory" during my Ubuntu install process.
    – Gabriel Staples
    Commented Jun 13, 2019 at 7:08
  • 1
    and a maximum path of 4096 characters is incorrect. PATH_MAX is just the maximum length for certain libc functions which can be worked around. There is no hard limit.
    – ssokolow
    Commented Sep 1, 2019 at 9:51
14

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.

Improve this answer
1
  • "it seems that you are fine until 143 characters" is only true as long as filenames are entirely made up of the original latin ascii character set, which uses 1 byte for 1 character in UTF-8. UTF-8 uses between 1-4 bytes per character (with the CJK characters using four bytes per character). The problem is also that "character" is an overloaded term, meaning different things to different people. Some graphemes (symbols/glyphs) may consist of multiple combining codepoints (each of which is 1-4 bytes). Therefore the only unit able to correctly describe the limits of the filesystem is bytes.
    – Travis Britz
    Commented Mar 28, 2022 at 1:52
12

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.

Improve this answer
4
  • 2
    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
    Commented May 30, 2016 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
    Commented Jun 1, 2016 at 19:01
  • 1
    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
    Commented Jun 7, 2016 at 16:00
  • And I think they'd have to kill off Windows an JavaScript first, too, since they both rely on UTF-16. (It might be possible to rectify this in JavaScript's case, though?)
    – SamB
    Commented Nov 4, 2016 at 4:58
4

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.

Improve this answer
1
  • Yea I guess workarounds are the only possible solution. Actually I wanted source code to be encrypted, so what I did was just using partition manager to shrink my home partition, then I've created new partition and encrypted it with LUKS. So all my personal data are stored in home/my_user, but the ones with problematic filenames I've just moved to new partition.
    – ZZ 5
    Commented Jun 17 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .