Synology, Encryption, and Unicode

by Rian

The whole shenanigans behind encrypted shared folder (ESF) goes way back. Personally I would start counting from pre-unicode era, during the period when each developers had whipped up its own solution for the problem. It is a problem that most developers did not truly understand, therefore most of their solutions were either flawed or limited.

Filename length limits on ESF stems from what Synology has opted to use to encrypt the shared folder: eCryptfs. It’s an encryption package developed for Linux environment, released in 2006, and has seen the last update in 2016. Given the lack of activities, Ubuntu has depreciated eCryptfs in favor of LUKS, something similar that of full volume encryption (FVE) on DSM. But fundamentally, for a package released in 2006, it is stunningly lacking in terms of unicode support.

Due to the design of its encryption system, eCryptfs lowers the possible filename length on DSM to 143 characters with ASCII. This is to say, with CJK names, the limitation is much severe than ASCII, only 47 characters. To reiterate how much of an impact this is, ESF limits filename to either 56% for ASCII or 18% for CJK unicode.

In late 2000s, unicode was already the most popular encoding on the web, and most operating systems, namely POSIX systems such as Linux, began adopting them as early as 1990s. My point here is that eCryptfs had no reason not to consider the harsher limitations on unicode, let alone the support for CJK languages. The blame should fall equally on Synology for choosing to use eCryptfs; I expect them to have an international QA team who uses other than English.

On the bug report filed in 2009, the original author of the package explained the technical difficulties of lifting the limitation, thereby proposed an alternative project, fscrypt, started in 2016. As I understand it, both are open source projects. While I do not wish to burden the authors and contributors of more responsibilities they have on their shoulders, I can’t help but notice the pattern that open source projects are being created and replaced so easily, when a single project with flaws can leave greater influence on the whole industry.

What does this mean for Synology and its DSM? I believe the answer comes in two folds: one, DSM will need an updated ESF, as eCryptfs is no more, two, for the users and prospective buyers of Synology NAS, I would recommend reevaluating where keeping only FVE is a viable solution. 47 characters are simply not enough. Unless you have a workflow already to compensate for the limitations, —I had a python script that separated out the long filename into a text file— it simply isn’t worth the trouble. If you have only couple of files that are being rejected, the search for the solution isn’t going to be a dignifying one.