Data-at-rest is persistent data stored on a physical storage device – hard disks or external storage devices – that is not being transferred over the network or used by the operating system and applications.
Keeping this data unencrypted exposes information of the user to be accessed in a fully readable form – either if the device is stolen or discarded without a proper data erasure. A potential adversary is thus able to gain various types of confidential data that can be commonly found on personal computers, like credit card numbers, medical reports or demographic information [14].
There are three main aspects determining the quality of data-at-rest encryption: the underlying encryption cipher, key strengthening and key management.
Encryption and key management
Data encryption
Symmetric cryptography is used in data-at-rest encryption to ensure confidentiality while preserving quick data access. The most ideal choice for a symmetric block cipher is the Advanced Encryption Standard (AES), standardized by NIST in FIPS PUB 197 [15].
Key strengthening
The encrypted data is mostly protected by a user-chosen password. These passwords can lack entropy to be resistant against brute-force and dictionary attacks, therefore are not applicable as an encryption key directly without further processing.
As recommended in PKCS#5 [16], the key for password-based cryptography should be derived by a password-based key derivation function (PBKDF): the password is combined with a random salt and iterated in a sufficient number of operations, usually involving usage of cryptographic hash functions. PBKDF2, described in PKCS#5, is a widely used CPU-intrusive PBKDF, which can significantly increase the time needed for derivation. However, PBKDF2 is vulnerable to parallel attacks [17], since it does not consume enough memory and the derivation can be accelerated by parallel computation, e.g., using a GPU instead of a CPU.
To address this weakness, new memory-hard algorithms [18] were developed, where not only iteration count, but also memory usage can be parametrized. Scrypt, published as RFC 7914 [19], or Argon2, a winner of the Password Hashing Competition in 2015 [20] published as RFC 9106 [21], are some remarkable memory-hard examples and potential future standards for key strengthening.
Key management
The most commonly desired approach to key management is a key hierarchy. The key derived from a user password is not used for encryption directly but to decrypt a strong, randomly generated master key. This way, the encrypted volume does not have to be re-encrypted each time the user changes their password.
Full disk encryption
Full disk encryption (FDE) operates with data of block devices – hard drives, disk partitions or loop devices. The FDE process, described in [22], takes place below the file-system layer: data of each disk sector is encrypted on-the-fly by a symmetric cipher before being stored physically on a disk device. The whole volume of the device is encrypted, FDE does not preserve any metadata.
The state-of-the-art symmetric cipher for FDE is the AES block cipher in XEX-based tweaked-codebook mode with ciphertext stealing (XTS). AES-XTS tweakable encryption mode was standardized in 2007 by IEEE [23] and recommended by NIST in 2010 [24]. The mode was designed for the cryptographic protection of data on storage devices, offering better protection against ciphertext manipulation than other common block cipher modes like Cipher block chaining (CBC) or Counter (CTR). The important tweak of AES-XTS lies in combining blocks with the disk sector number, which acts as an initialization vector. Without this tweak, the encryption would suffer from vulnerabilities of the Electronic Code Book (ECB) mode since the XTS mode is deterministic and non-chained.
Filesystem encryption
Encryption of data on the filesystem layer provides encryption of individual, specified files. The encryption is often applied only on the content of files, not on file system metadata, such as file size, permissions or modification timestamps.
Filesystem encryption can provide an additional layer of security. Users can create a folder for confidential files, which is encrypted even when the system is running, unless mounted. This approach prevents stealing data from a running system or execution of a cold boot attack [25].
Many solutions implement this approach by a stackable filesystem, which resides on top of an existing one. It is responsible for encrypting all writes and decrypting all reads from encryption-enabled files of the underlying filesystem.
Some filesystems, for example Ext4 or ZFS, provide a directly integrated native file encryption, which is more memory efficient.
Candidates
The set of considered options for full disk encryption consists of LUKS2 by cryptsetup, VeraCrypt and ZuluCrypt. Encfs, eCryptfs, gocryptfs, fscrypt and Cryptomator were evaluated as file encryption candidates. This section describes suitable candidates only and further results are described in the appendix, with a summarized overview in Table Overview.
LUKS2 (Linux Unified Key Setup version 2)
Linux Unified Key Setup version 2 (LUKS2), described in [26], is a platform-independent disk encryption format implementing the Template Key Setup 1 – a template design for secure key management. LUKS2 covers all the functionality of the predecessor version LUKS1. LUKS2 additionally addresses limitations of LUKS1 and provides new features, yielding better protection against header damage and support for functionality extensions without the need of changing the header structure.
Each partition starts with the LUKS partition header in plaintext. It contains essential encryption metadata, like the encryption cipher, cipher mode or hash digest of the primary key for verification. The header is followed by key slots with information about user keys, where the number of slots determines the number of passwords that can be used for encryption of one single LUKS partition. The rest of the disk contains actual encrypted user data.
The LUKS format comes with a number of usability and security qualities:
- each of the passwords can be changed or revoked individually without re-encrypting the device,
- each user password is strengthened by a key derivation function,
- anti-forensic information splitting is applied for storage of the primary key physically on the disk.
Thanks to these features LUKS protects low-entropy user passwords from brute-force and dictionary attacks and decreases the probability of extracting the primary key from an insufficiently erased disk by spreading the key across disk blocks. This way, if just one of the disk blocks is damaged, the key cannot be recovered.
In terms of KDF iteration count, LUKS selects the count as a result of a runtime evaluation of a chosen PBKDF, yielding in a good compromise between brute-force attack defense and encryption speed. The iteration count is influenced by many factors and more than two million iterations [27] can be achieved in specific system conditions.
A damaged LUKS header can lead to a permanent loss of data. It is strongly recommended to make a header backup to prevent data against the header being overwritten accidentally or against dysfunction of the physical device. LUKS2 headers can also be detached and stored separately, leaving the encrypted device without any visible metadata [26].
The cryptsetup CLI utility is used to conveniently set up LUKS partitions on top of dm-crypt, described in dm-crypt. LUKS2 is used as the default version. cryptsetup also allows opening TrueCrypt, VeraCrypt and BitLocker devices, but provides formatting for LUKS only. By default, cryptsetup encrypts LUKS2 devices using AES-XTS with a 256-bit primary key. The primary key is derived by the Argon2id PBKDF.
VeraCrypt
VeraCrypt is an open-source disk encryption software available for Windows, MacOS, Linux, FreeBSD and Raspberry Pi systems. It is a fork of a discontinued project named TrueCrypt, based on its latest version 7.1a.
The header of a VeraCrypt device is, in contrast with LUKS, encrypted. The encrypted disk should not be distinguishable from a disk filled with random data. Veracrypt claims to provide a form of plausible deniability by creating hidden volumes or a hidden operating system, but according to Kedziora et al. [28], there is a number of attack vectors potentially proving existence of a hidden volume.
System encryption with pre-boot authentication is currently available for Windows systems only.
VeraCrypt’s PBKDF iteration count is fixed to 655331 iterations [29]. Even though the number is sufficient according to NIST [30] in terms of defense against brute-force attacks, the encryption is not optimized for legacy software and thus might be very slow. The iteration count can be determined by a Personal Iterations Multiplier (PIM), an extra numeric value supplied by the user. However, the PIM value needs to be remembered by the user together with the password, which significantly lowers the usability.
VeraCrypt provides a GUI, but unfortunately it violates a lot of usable security properties. The current user interface design allows users to create an insecure environment easily and make irreversible mistakes. Design improvements have been suggested [31] to achieve a more intuitive, secure and visually pleasing interface, but have not been applied so far. VeraCrypt therefore cannot be recommended for beginner users.
TrueCrypt has historical issues with licensing and its latest version is licensed under the TrueCrypt License, which is not considered as open-source under the OSI’s Open Source Definition. VeraCrypt is licensed under the Apache License 2.0 and also inherits the predecessor TrueCrypt License. Even though the Apache License is present on the OSI’s list of approved open-source licenses, VeraCrypt could be still considered as a third-party software. It may therefore not be included in official repositories of some Linux distributions and need to be installed manually.
Figure 1: Crowded GUI of VeraCrypt.
gocryptfs
gocryptfs is a userspace stackable cryptographic filesystem released under the MIT license. It is inspired by Encfs,, which development is no longer active. gocryptfs aims to cover security issues of Encfs and provide better performance and portability. gocryptfs is supported on macOS systems and cppcryptfs, a re-implementation of gocryptfs, allows management of gocryptfs filesystems on Windows systems.
Filesystem in USErspace (FUSE), an open-source secure userspace filesystem framework, is used to mount the encrypted filesystem on another. Since FUSE provides non-root filesystem administration, any user can create an encrypted filesystem. When a FUSE filesystem is mounted, any other user, even root, cannot access the volume [32]. AES in Galois/Counter (GCM) and Encrypt-Mix-Encrypt (EME) mode are the default encryption ciphers for file content and file names, respectively. Scrypt is used for key strengthening.
fscrypt
fscrypt is a Linux native filesystem encryption solution. It is a kernel module released under the GPL license with a corresponding userspace tool with the same name, released under the Apache License version 2.0.
fscrypt currently supports encryption of ext4, F2FS and UBIFS filesystems, but generally supports all filesystems complying with requirements described in the design document [33]. By default, fscrypt uses Argon2id as a PBKDF with hardware-optimal hash parameters, AES-XTS for encryption of file content and AES in Ciphertext Stealing (CTS) mode for encryption of filenames. Userspace version of fscrypt may need to be built and installed manually.
Cryptomator
Cryptomator is an open-source project focused on client-side encryption of cloud file containers. It supports any cloud storage providers that can be synchronized with a local directory on the system. Two formats for the virtual filesystem are available – FUSE and WebDAV. Cryptomator is fully supported on macOS and Windows. However, the Windows version uses Dokany, a different implementation of the virtual filesystem. To ensure portability, the Cryptomator Portable application was developed by Portapps.
The strongest advantage is the Cryptomator GUI, as shown in Figure 2. The visual design is modern and clean, as opposed to other data-at-rest encryption GUI designs like VeraCrypt or ZuluCrypt. The terminology and workflow are tailored to be understandable even without previous knowledge of filesystem encryption. Users get clear feedback on their actions, and following default operations does not allow mistakes or create an insecure environment. Some of the notable features are:
- restricted usage of weak passwords,
- provision of a recovery key in case of a forgotten password,
- automatic locking of mounted filesystems,
- automatic selection of mount points.
All of these qualities ensure compliance with principles of usable security and possibility of usage by beginner users.
Data is encrypted by AES-CTR with filenames encrypted by AES in Synthetic Initialization Vector (SIV) mode. The primary key is derived by Scrypt.
This software is dual-licensed under the GPLv3 and a commercial license for the Cryptomator Android application, thus may need manual installation. On Linux systems, it is recommended to run Cryptomator via an AppImage executable.
Figure 2: Clean GUI of Cryptomator.
Data-at-rest encryption recommendations
Considering usage of disk encryption tools by beginner and intermediate users, only two candidates were chosen: LUKS encryption by cryptsetup and VeraCrypt. These tools hide a fair amount of encryption-related setup and have appropriate default encryption options considering mentioned security standards – AES symmetric cipher is used in XTS mode for data encryption, as recommended in [23], and user passwords are strengthened by a PBKDF. Both of these tools come with some kind of a GUI – VeraCrypt has its own GUI application, and creating LUKS partitions can be integrated directly into the desktop environment. A more detailed comparison of LUKS2 by cryptsetup and VeraCrypt can be found in Table LUKS2 by cryptsetup versus VeraCrypt.
LUKS is evaluated to be the most suitable disk encryption solution. It is a standard for users with Linux kernel systems for a multiple of reasons. No additional installation is required, since dm-crypt is a kernel module and cryptsetup is available in repositories of all Linux distributions.
System encryption can be set up conveniently during the installation of a distribution and is strongly recommended for both types of users: the whole system gets encrypted and there is no need to take care of encrypting temporary files or swap space, where applications might silently store confidential data. LUKS encryption is also optimized for specific hardware and uses a modern, memory-hard PBKDF Argon2id by default. All of these reasons are rendering VeraCrypt less appropriate.
VeraCrypt is still kept as another recommendation for multi-platform users, because in contrast with LUKS, VeraCrypt devices can be formatted across different operating systems. Using a portable filesystem type on the device, like FAT32 or exFAT, the device can be opened on any system with VeraCrypt installed or cryptsetup available. This approach is recommended for intermediate users only, since the VeraCrypt GUI application shows weaknesses in terms of usable security and is considered unsafe for beginners.
File encryption can be recommended for concerned users on top of system disk encryption. Intermediate users can use fscrypt for encrypting files locally on their filesystem. It is a memory-efficient solution, but it is not portable across operating systems, gocryptfs is another simple CLI for intermediate users based on stacking a FUSE virtual filesystem. Thanks to FUSE, gocryptfs is not dependent on specific filesystems and is also portable with macOS and Windows.
Both beginner and intermediate users can store confidential data on the cloud encrypted by Cryptomator. The GUI is tailored to be usable and make the encryption simple, with secure default encryption options and some extra features like automatic locking of decrypted directories or automatic application updates.
LUKS2 by cryptsetup versus VeraCrypt
| cryptsetup – LUKS2 | VeraCrypt | |
| system encryption | 🗸 | 𐄂 (Windows only) |
| key derivation function | 🗸 | 🗸 |
| encryption metadata* | 🗸 | 🗸 |
| anti-forensic splitting** | 🗸 | 𐄂 |
| online re-encryption | 🗸 | 𐄂 |
| automounting | 🗸 | 🗸 |
| number of passwords /per volume | multi-keyed – up to 32 | single-keyed |
| virtual disks | 🗸 | 🗸 |
| Windows support | with additional tools only | 🗸 |
| macOS support | 𐄂 | 🗸 |
| license | GPLv2 | Apache 2.0 + TrueCrypt License 3.0 |
| default cipher | AES-XTS | AES-XTS |
| default KDF | Argon2id | PBKDF2 |
* Encryption metadata is stored in the header of encrypted volume, so encryption options do not need to be provided by the user in order to decrypt the device.
** Anti-forensic splitting prevents recovery of the primary key from an insufficiently erased disk by diffusing the key information across several disk sectors.
Overview
| license | latest version as of May, 2022 | default encryption | Default PBKDF |
supported platforms | |
| LUKS2 by cryptsetup | GPLv2 | V2.4.3 Jan 13, 2022 |
AES-XTS | Argon2id | Linux |
| VeraCrypt | Apache 2.0 + TrueCrypt 3.0 | V1.25.9 Feb 20, 2022 |
AES-XTS | PBKDF2 | Linux, Windows, macOS |
| ZuluCrypt | GPLv2 | V6.0.0 Jan 29, 2021 |
underlying implementation | underlying implementation | Linux |
| eCryptfs | GPLv2 | V111 May 2, 2016 |
AES-? | ? | Linux |
| Encfs | LGPL | V1.9.5 Apr 27, 2018 |
AES-? | PBKDF2 | Linux, macOS |
| gocryptfs | MIT | V2.2.1 Oct 20, 2021 |
AES-GCM for file content, AES-EME for file names | Scrypt | Linux, macOS |
| fscrypt | Apache 2.0 | V0.3.3 Feb 23, 2022 |
AES-XTS for file content, AES-CTS for file names | Argon2id | Linux |
| Cryptomator | GPLv3 | V1.6.10 May 3, 2022 |
AES-CTR for file content, AES-SIV for file names | Scrypt | Linux, Windows, macOS |
Appendices
dm-crypt
Volume management in Linux systems is provided by the Device Mapper, an infrastructure included in the Linux kernel. The Device Mapper creates virtual block devices on top of physical ones. It comes with the dm-crypt kernel module, which provides low-level disk encryption by encrypting data being passed from virtual to physical block layers using the Linux CryptoAPI. The list of available CryptoAPI ciphers can be found in /proc/crypto.
An encrypted volume created by the dm-crypt module does not contain any available encryption metadata. Correct encryption information and a correct password must be supplied to correctly decrypt volume, otherwise the data will be overwritten and possibly lost. The user is responsible for providing corresponding encryption options and a sufficiently strong passphrase as well, since no key derivation function is used.
dm-crypt is unconsiderable for both user types since no storage of encryption metadata makes it severely unusable and prone to data loss. The LUKS encryption format by cryptsetup uses dm-crypt for the low-level implementation and offers several usability enhancements described in Section Linux Unified Key Setup 2 (LUKS2).
Encfs
Encfs is a stackable cryptographic filesystem working in userspace. The FUSE API is used for mounting of the encrypted filesystem.
The user can choose from three encryption modes – standard, paranoia and expert – with different encryption options for each category. Passwords can be changed using encfsctl, a tool for management of Encfs filesystems.
Encfs is also available for macOS, additional tools are needed to mount Encfs filesystems on Windows. Nonetheless, the development of this tool is inactive. gocryptfs is an actively maintained alternative inspired by Encfs.
eCryptfs
The Linux kernel provides eCryptfs, a stackable cryptographic filesystem, since version 2.6.19. The ecryptfs-utils package can be downloaded from official repositories, which provides userspace tools for easier eCryptfs setup.
However, the setup is unintuitive even with ecryptfs-utils since the functionality is divided into multiple commands instead of one centralized API. In addition, the latest stable version of eCryptfs is currently almost six years old and can be considered non-maintained [79, 80]. eCryptfs is thus being deprecated in favor of new solutions.
ZuluCrypt
ZuluCrypt provides a universal CLI and GUI for management of disk encryption on Linux systems. This utility can work with any type of block device and supports various formats: volumes encrypted with dm–crypt, LUKS1 and LUKS2 devices, TrueCrypt and VeraCrypt.
Even though usability is the main idea behind this utility, bringing different formats into one GUI does not serve the purpose in the tested version of ZuluCrypt and it cannot be recommended to any user type.
The application is lacking guidance and clarity for beginner users. Following default options to create an encrypted volume, the process failed multiple times without any helpful explanation, as shown in Figure 4. It is also more convenient for intermediate users to use cryptsetup or VeraCrypt directly, because previous understanding of the underlying encryption tools is needed to use ZuluCrypt efficiently.
Figure 3: Crowded GUI of ZuluCrypt.
Figure 4: ZuluCrypt dialog without any guidance to prevent failure.