Jump to content

LUKS/Advanced

From FASSAG Wiki
Revision as of 01:47, 17 June 2026 by VV (talk | contribs) (remove "main page" link)
This article is currently a draft. It has not yet been completed.

This is an Intermediate difficulty guide. All versions:

For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki.

Guide to Decent LUKS Security on Linux

The Main Page gives a high level overview of what different LUKS options can do, but this page intends to go into as much detail as possible about them while still aiming to be easy to understand.

Ciphers

Ciphers are the algorithms used to encrypt data. Picking the best algorithm is very important for ensuring your data is secure. If your cipher can be broken, then your data can be accessed without the key.

Of the widely supported options, the two most worth considering are Serpent and AES.

Twofish may be better in lower-security applications where there's no AES acceleration and writes happen more often than reads, but generally, not a great option.

Serpent may theoretically be more secure, though in practice its potential advantages seem pretty minimal. It also hasn't been tested as much as AES, so it may have potential vulnerabilities not yet known about .

Another consideration is the actual implementation. Serpent has potential vulnerabilities depending on the details of the implementation. Without looking into the specific implementation in-depth, it's hard to say how secure it is.

On the other hand, having hardware acceleration for AES has a number of advantages for security, most notably resistance to side channel attacks, and of course, speed. Some chips however, almost always not x86, do not have hardware accelerated AES. It's also possible that your CPU may have a vulnerability, so that's something you may want to look into. As far as we are aware though, no vulnerabilities have been reported on any present or past chip with AES support. Practically speaking, the advantages of having hardware accelerated AES make it more secure than using Serpent in nearly all cases.

On-disk Format

The on-disk format defines how the encrypted data is stored on the disk itself . While you could just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .