eCryptfs允许的最大文件名（和文件夹）大小是多少？

我是eCryptfs的新用户，但有一个非常基本的问题，我找不到任何地方。我对通过使用Linux的Synology NAS使用eCryptfs感兴趣。

尝试通过Synology的加密应用程序（eCryptfs）加密我的文件夹（EXT4）时，遇到错误，指出我的文件名长度不能超过45个字符（因此，没有加密）。

如果限制的确是45个字符，则eCryptfs对于大多数人可能不是可用的工具。

使用eCryptfs加密文件和文件夹时，允许的最大文件名大小是多少？是255个字符吗？

全面披露：我是eCryptfs用户空间实用程序的作者之一和当前维护者。

好问题！

对于大多数文件系统（包括EXT4），Linux的最大文件名长度为255个字符，最大路径为4096个字符。

eCryptfs是一个分层文件系统。它堆叠在另一个文件系统（例如EXT4）的顶部，该文件系统实际上是用于将数据写入磁盘的。eCryptfs始终加密文件内容，但是可以选择加密（模糊）文件名（或不加密）。

如果文件名未加密，则可以安全地写入最多255个字符的文件名并对其内容进行加密，因为写入较低文件系统的文件名将完全匹配。虽然攻击者无法读取index.html或的内容budget.xls，但他们将知道存在哪些文件名。根据您的用例，这可能会（或可能不会）泄漏敏感信息。

如果文件名被加密，事情会变得更加复杂。eCryptfs在加密文件名的前面添加了一些数据，以便它可以确定识别加密文件名。同样，加密本身涉及“填充”文件名。

例如，我有一个加密文件~/.bashrc。该文件名使用我的密钥加密：

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

显然，这7个字符的文件名现在需要加密7个以上的字符。根据经验，我们发现超过143个字符的字符文件名开始需要> 255个字符进行加密。因此，我们（作为eCryptfs上游开发人员）通常建议您将文件名限制为〜140个字符。

综上所述，Synology NAS是一种商业产品，嵌入并使用eCryptfs和Linux来加密和保护设备上的数据。我们（eCryptfs的上游开发人员）与Synology或其产品无关，尽管我们通常很高兴看到野外使用eCryptfs 。在我看来，他们对45个字符的推荐要么是印刷错误（来自我们140个字符的推荐），要么仅仅是一个更为保守的估计。

这个线程非常有趣，因为我想知道完全相同的事情。如果文件名必须小于或等于140个字符，那么我可以重命名500000个文件中的20个文件，但是（在我的情况下）不超过45个字符是不可行的，因为这将需要我重命名太多的文件。

我直接向Synology提出了完全相同的问题（甚至指向他们指向本文），他们的回答很有趣：“加密共享的文件名限制为143个字节。最大可以是140个纯拉丁字符或45个CJK（中文） ，日文和韩文）字符。”

遵循此答案，我对自己进行了更多测试，使用45、46、140、143和144个字符的文件进行了测试。我的测试表明，最多143个字符的文件（不是字节，与Synology告诉我的相反）将被加密，但是144个字符的文件将防止文件夹被加密。但是，我从NAS收到的错误消息是文件名必须少于45个字符（而现实情况是文件名应少于144个字符）。

我没有使用CJK字符进行测试...但是，对于阅读本文的任何人来说，尽管系统告诉了您，但直到143个字符似乎还不错。

我想澄清一下，Linux每个文件名的限制为255个字节，而不是255个字符。这是一个很大的差异，如果使用例如UTF-8编码，则最终文件名最多为100个字符。

ecrypt的文件名长度对我来说只是一个问题，因为我需要主目录中的特定子树来支持长文件名，最终我意识到我可以简单地在文件内创建文件系统并将其挂载：

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

可能存在各种效率问题，但对于我的情况来说，这只是文件的测试结果，这些结果是出于我自己的本地目的而定期创建的，这已经足够了。

我的同事将他们的图像放在/ tmp中-测试数据不是特别机密：我们主要是要保护我们的源代码，而不是测试结果。