Many Linux distributions including those used in off the shelf Network Attached Storage (NAS) devices have the ability to protect users’ data with one or more types of encryption. Full-disk and folder-based encryption options are commonly available, each with its own set of pros and contras. The new native ZFS encryption made available in OpenZFS 2.0 is designed to combine the benefits of full-disk and folder-based encryption without the associated drawbacks. In this article, we’ll compare the strengths and weaknesses of LUKS, eCryptFS and ZFS encryption.

Encryption in NAS Devices

While Linux users may or may not encrypt their data, all major manufacturers of Network Attached Storage (NAS) devices offer some sort of encryption at least in some models. We have published a number of articles about the types of encryption used in the various NAS devices:

• NAS Forensics: TrueNAS Encryption Overview
• NAS Forensics: QNAP Encryption Analysis
• Attached Storage Forensics: Security Analysis of ASUSTOR NAS
• Attached Storage Forensics: Security Analysis of TerraMaster NAS
• Attached Storage Forensics: Security Analysis of Thecus NAS
• Synology NAS Encryption: Forensic Analysis of Synology NAS Devices

In addition, we published an article on Breaking LUKS Encryption. Finally, we have a great overview comparing the types of encryption used by the various NAS vendors in NAS Forensics: Synology, ASUSTOR, QNAP, TerraMaster and Thecus Encryption Compared. As you can see from the table below, while some vendors opt for either LUKS or eCryptFS, Asustor offers the choice of LUKS or eCryptFS for the different types of volumes, while Qnap allows cherry-picking or stacking SED, LUKS and eCryptFS encryption. TrueNAS is missing from the table; the classic FreeNAS and TrueNAS Core support GELI (FreeBSD full-disk encryption method) and native ZFS encryption, while TrueNAS Scale only supports native ZFS encryption.

LUKS

LUKS (Linux Unified Key Setup) is a well-known, secure, and high-performance disk encryption method based on the classic dm-crypt. Originally developed for the Linux OS, LUKS is widely used across many types of devices running all kinds of Linux distributions. It is also a popular encryption format in Network Attached Storage (NAS) devices.

LUKS supports a range of different hash functions and encryption algorithms including AES, Serpent, Twofish, CAST-128 and CAST-256 in ECB, CBC-PLAIN64, CBC-ESSIV:hash or XTS-PLAIN64 modes. The default option in most Linux distributions is cbc-essiv:sha256 that uses AES encryption with a 256-bit key. Being the only hardware-accelerated encryption algorithm, AES is by far the most common of the three, especially when used in enterprise environments and network attached storage (NAS) devices. AES encryption offers that highest stream cipher performance when used on chip sets featuring AES encryption acceleration (e.g. the AES-NI instruction set in Intel CPUs). Serpent and Twofish can be manually specified by the user at the time of creating the encrypted volume, yet they offer no tangible benefit in security over AES with a significant performance penalty.

In disk encryption, hash functions are used as part of the Key Derivation Function (KDF). KDF are used to derive the binary wrapping key out of the user-provided input (typically, a text-based passphrase). The following hash functions are supported in the LUKS specification: SHA-1, SHA-256, SHA-512, RIPEMD160 and WHIRLPOOL. The SHA-1 and RIPEMD160 are explicitly not recommended; the SHA-256 is used by default, yet SHA-512 and WHIRLPOOL can be manually specified.

Most Linux-based appliances automatically use the default settings, while users can manually specify alternative hashing and encryption settings at the time they encrypt the disk on their Linux computer. LUKS stores information about the selected encryption settings in the encryption metadata, making it possible for the attacker to determine the correct encryption settings ahead of launching the attack.

A single LUKS volume may be protected with more than one key. The specification allows multiple user keys to decrypt the master key that is used for encryption. As a result, a LUKS-encrypted device may contain multiple key slots, which are used to store backup keys/passphrases and to allow multiple users unlock LUKS volumes each with their own password. Each key slot is protected with a unique salt, making the reverse brute force attack (matching the same KDF of a password against the different slots) unfeasible. A KDF must be calculated separately for each key slot during the attack. As a result, attackers will have to select a particular key slot to brute-force. Another result is the fact that, if the last available key slot is cleared, the entire LUKS-encrypted disk becomes inaccessible and non-decryptable (unless a copy of encryption metatada was backed up with cryptsetup luksHeaderBackup). Erasing the encryption metadata effectively implements near-instant secure erase of the encrypted disk.

LUKS encrypts the whole disk, and delivers very high performance. The whole-disk encryption has its drawbacks, too. LUKS encrypted volumes must be mounted (with the matching key or password) to perform operations on the file system. One needs the encryption key to check the file system for consistency, verify data integrity, create, restore or replicate snapshots, or make backups of encrypted data (other than saving a copy of the entire partition).

Of these problems, the difficulties in creating and restoring backups without unlocking the volume and decrypting the data was the one that triggered the development of an alternative encryption scheme.

You can read more about the LUKS encryption system as well as setting up a password recovery attack on LUKS-encrypted disks in our older article Breaking LUKS Encryption.

Filesystem-level Encryption

The most common implementation of filesystem-level encryption in Linux is eCryptFS, an open-source cryptographic file system.

eCryptFS supports several encryption algorithms including AES, Blowfish, DES3_EDE, Twofish, CAST6 and CAST5. Similar to other encryption tools, using any encryption algorithm other than AES will unnecessarily slow down the encryption without delivering tangible benefits in security.

eCryptFS is a file-based encryption system that encrypts individual files and stores them on top of the regular file system. Optional encryption of file and folder names is also available, which limits the maximum length of the file names to 143 ASCII characters.

Each file is encrypted with a unique, randomly generated session key, which in turn is encrypted (wrapped) with the user’s key or passphrase. The wrapped key is saved in the encryption metadata, which gets stored in each file’s header. This way, each encrypted file becomes self-contained, which allows seamlessly copying individual files or folders onto a different computer.

This implementation effectively lifts the restriction of requiring the encryption key to perform file system maintenance, back up and restore files and folders. For example, system administrators can backup and restore users’ home folders without having access to each user’s encryption keys, while NAS manufacturers implement blind backups to untrusted destinations via snapshot replication.

The ability to back up and restore encrypted data without asking for a key is pretty much the only benefit of eCryptFS. Everything else about this encryption method is a drawback.

1. Encryption overhead, low performance. eCryptFS adds encryption metadata to each encrypted file, which hurts performance (especially for smaller files) and adds storage overhead.
2. Information leakage. eCryptFS encryption leaks information about the size of each encrypted folder; the number, size, date and attributes of each file, allowing profiling attacks.
3. Cannot change encryption password (NAS). Off the shelf NAS units made by Synology, Asustor and other manufacturers do not allow revoking or changing compromised passwords. The only way to change the password is decrypting and re-encrypting the entire dataset.
4. Functional limitations. If the option to encrypt file names is enabled, the names cannot be longer than 143 ASCII characters (or even less if Unicode characters appear in the names). There are other restrictions, too, such as lack of NFS support for encrypted shares.
5. Some file system functions are unavailable. For example, BTRFS deduplication features will not work on encrypted datasets.

These limitations made the developers think about a different, modern encryption method. Meet native ZFS encryption, part of OpenZFS 2.0.

ZFS Encryption

First and foremost: native ZFS encryption is only available on disks using the ZFS file system, particularly via OpenZFS 2.0. While ZFS native encryption protects the entire dataset, it is different from traditional full-disk encryption schemes such as LUKS. Namely, some ZFS metadata such as the size of the file system (but not the number or sizes of individual files and folders) is exposed even without an encryption key, along with deduplication tables. On the other hand, users can scrub encrypted datasets, perform maintenance operations, create and replicate snapshots and basically do everything that zfs and zpool commands can do. Unlike filesystem-level encryption methods such as eCryptFS, ZFS native encryption allows changing the password without re-encrypting the dataset. Ars Technica published a very nice Quick-start guide to OpenZFS native encryption that is well worth reading.

When creating an encrypted dataset, the user can specify the encryption algorithm (the default is AES-256-GCM) and, in the case of passcode-based encryption, the number of pbkdf2 iterations (the default is 350,000).

By design, ZFS encryption has several weaknesses that leak certain type of information about encrypted datasets. The first piece of information is the name and size of the file system, as well as other information available through the use of the zfs and zpool commands. I want to say it again: unlike eCryptFS, ZFS native encryption does not leak the number and size of encrypted files and folders.

ZFS encryption does not protect deduplication tables, which leaks the addresses of duplicate blocks on the disk (but not the content of individual data blocks). There are some changes in the way of IV generation outlined in the following slide from the presentation of ZFS encryption:

How ZFS encryption works

ZFS encrypts data with AES-256 in GCM mode by default, with options for 128, 192 or 256-bit keys and CCM or GCM modes. Information about the encryption algorithm, key length and mode is stored in the encryption metadata. The encryption key is protected (wrapped) with a key generated with a certain number of iterations of PBKDF2. By default, 350,000 iterations are used; however, the user can specify a different number (but no less than 100,000 iterations).

Encrypted pools are created with the following command:

zfs create -o encryption=[algorithm] -o keylocation=[location] -o keyformat=[format] poolname/datasetname

Users can create encrypted pools that can be automatically mounted on boot. This requires the use of a binary key that is stored in a file (file:///path/to/keyfile). The encryption key is strictly 32 bytes, and should be comprised of random data. A random encryption key can be generated with the following command: if=/dev/urandom bs=32 count=1 of=/path/to/keyfile

Datasets that without auto-mount can be encrypted with either a binary key or a password. If a password is used, it must be 8 to 512 characters long.

zfs create -o encryption=aes-256-gcm -o keyformat=passphrase poolname/ datasetname

Notably, ZFS does not use the key or the password to directly encrypt the data set. Similar to LUKS and other disk encryption methods such as BitLocker, ZFS encrypts data with a master key. The master key, in turn, will be encrypted (wrapped) with a key encryption key (KEK), which can be either a user-provided binary key or the result of N iterations of PBKDF2 performed on the user’s passphrase.

(Source: presentation of ZFS encryption)

To sum it up, ZFS encryption has the following properties:

• AES encryption only. No third-party encryption algorithms or hash functions supported for the time being.
• Performance is comparable to non-encrypted pools regardless of file size.
• Password protection can be strengthened by using a larger number of hash rounds.
• Encrypted datasets leak several types of data, all of which are insignificant.
• Deduplication does affect security, and should be disabled for critical data.
• Blind backups and snapshot replication to untrusted destinations supported without the encryption key.
• Can be used to protect disks or individual datasets.

Conclusion

Traditional encryption methods used in Linux computers and storage appliances are all about tradeoffs. Filesystem-level encryption via eCryptFS lacks in nearly every respect. eCryptFS is slow, has a non-zero storage overhead, leaks information about encrypted data (including the size and number of files in the folders), and does not allow changing the encryption password. eCryptFS is a crippled file system, restricting the maximum file name length to only 143 characters, and limiting the use of certain features such as online deduplication or NFS support.

Full-disk encryption (LUKS) is faster, more secure and more convenient compared to eCryptFS, yet it does limit functionality in a different way: one cannot snapshot LUKS-encrypted volumes without unlocking them first; backup and restore functionality is unavailable on encrypted datasets without entering the encryption key; one cannot scrub the data or perform file system maintenance without providing the encryption key. The many “can’t” are easily possible with eCryptFS, the very encryption option I criticized above.

ZFS native encryption addresses all the points of critique mentioned above. High-speed data access, the ability to change encryption keys and passwords, support for filesystem-level maintenance operations such as scrubbing, snapshots of locked data sets, blind replication to untrusted remote destinations and a lot more things can be done on ZFS-encrypted datasets without entering an encryption key. Users can customize encryption options and attack resistance (via a custom number of hash iterations).

While ZFS native encryption does have its share of drawbacks, most of them are relatively minor. The most prominent drawback is ZFS itself: one must use the ZFS file system in order to use native ZFS encryption. This is very different from filesystem-agnostic LUKS and eCryptFS encryption: LUKS works one layer under, and eCryptFS one layer above the file system. If you do use ZFS, however, then its native encryption method is the most well-rounded encryption method available for Linux computers and NAS appliances. While it leaks more information about encrypted data compared to LUKS, it’s infinitely more convenient than the former. Compared to filesystem-level encryption, it’s several generations ahead. If you are flexible about the file system, I suggest checking out ZFS and its native encryption to secure your data.