LUKS

LUKS (Linux Unified Key Setup) is the standard on-disk format for block device encryption on Linux. It defines a header that sits at the start of an encrypted partition or volume and stores everything needed to unlock it: the cipher specification, key slots protected by passphrases or key files, and integrity metadata. The actual encryption of data is performed by the kernel’s dm-crypt subsystem, while LUKS supplies the key management layer on top.

In Linux security, LUKS is the usual answer to the question of how to protect data at rest when a laptop is stolen, a server disk is returned for warranty, or a drive is decommissioned. It does not protect a running, unlocked system; it protects the contents of a powered-off or locked device against anyone who lacks a valid key.

How LUKS separates the master key from passphrases

LUKS works by encrypting the disk with a single random volume key (often called the master key) and then storing that key several times, each copy wrapped by a different user secret. When a passphrase is entered, LUKS runs it through a key derivation function, uses the result to decrypt one key slot, verifies the recovered volume key against a stored digest and hands it to dm-crypt.

This design has an important consequence: changing a passphrase does not re-encrypt the disk. Only the small key slot is rewritten, which takes seconds. Conversely, revoking a leaked volume key requires a full re-encryption, because every sector depends on it.

To make key slots resistant to partial recovery from failing flash or magnetic media, LUKS spreads each wrapped key across many sectors with an anti-forensic splitter. Overwriting even a small part of that area makes the slot unrecoverable, which is why erasing the header alone is an effective way to destroy access to a volume quickly.

The following table lists the main components of a LUKS volume and the role each one plays.

LUKS1 and LUKS2 compared

LUKS2 is the current format and the default in cryptsetup since version 2.1; LUKS1 remains supported for compatibility with older boot loaders. LUKS2 stores its metadata as JSON, keeps a redundant copy of the header, supports more key slots and adds memory-hard key derivation.

The table summarizes the practical differences an administrator meets when choosing a format.

The boot loader limitation is the most common reason to keep LUKS1 or a PBKDF2 slot: many GRUB builds cannot evaluate Argon2, so an encrypted /boot may refuse to unlock. Keeping /boot unencrypted, or using a unified kernel image with systemd-boot, avoids the issue.

Key derivation, ciphers and parameters

The strength of a LUKS volume against offline guessing depends mainly on the passphrase entropy and the cost of the key derivation function. Argon2id deliberately consumes memory and time, so each guess on a stolen disk costs an attacker significant resources. cryptsetup benchmarks the machine when a slot is created and targets roughly two seconds of unlock time by default.

The parameters below are the ones most often tuned with cryptsetup luksFormat and their typical values.

On processors with AES-NI or equivalent instructions, AES-XTS adds little overhead and is the sensible default. On low-power devices without AES acceleration, Adiantum offers better speed. Neither choice changes LUKS itself; it only changes the cipher string recorded in the header.

Where LUKS fits among Linux security controls

LUKS addresses physical theft and media disposal, a different threat from those handled by mandatory access control or system call filtering. AppArmor, SELinux and Seccomp restrict what processes may do on a running system, whereas LUKS only matters when the volume is locked. A complete hardening plan uses both layers.

The comparison clarifies which layer answers which threat.

Unlike file-level schemes such as fscrypt, LUKS encrypts the whole block device, including file names, free space and swap if configured. The trade-off is granularity: once unlocked, every user with file permissions can read the data.

Practical setup and unlocking methods

LUKS volumes are created and managed with cryptsetup, mapped at boot through /etc/crypttab, and usually carry LVM or a single file system inside. A typical lifecycle uses luksFormat, open, luksAddKey, luksKillSlot and luksHeaderBackup.

• Passphrase at boot: simplest and portable, but requires a person at the console.
• TPM2 binding with systemd-cryptenroll: unattended unlock tied to measured boot state.
• FIDO2 security key: unlock with a hardware token and optional PIN.
• Network-bound unlock with Clevis and Tang: servers unlock only inside a trusted network.
• Key file on separate media: useful for data disks, risky if stored beside the volume.

Always keep at least one recovery passphrase in a separate slot when hardware tokens or TPM binding are used, because firmware updates can change measurements and block automatic unlocking.

Limitations and common mistakes

LUKS gives strong protection only within its threat model, and several operational mistakes undo it. The most frequent ones are listed below.

• No header backup: a damaged header makes the data permanently unreadable, even with the correct passphrase.
• Weak passphrases: Argon2id slows guessing but cannot rescue a short dictionary word.
• Assuming protection while running: an unlocked volume is readable by anyone with system access, and the volume key sits in RAM.
• TRIM leakage: enabling discards reveals which blocks are unused, a minor but real metadata leak.
• Evil maid attacks: an unencrypted /boot can be modified to capture the passphrase unless Secure Boot and measured boot are in place.

Explained without jargon

Think of LUKS as a safe with several keyholes. The disk is locked with one strong internal key that nobody types. That internal key is kept inside the safe several times, and each copy is locked with a different password or hardware key.

When you start the computer and enter your password, the safe opens one copy, takes out the internal key and lets the system read the disk. If the laptop is stolen while switched off, the thief sees only scrambled data. Changing your password is quick because only one keyhole changes, not the whole disk.

A typical use case

A small engineering firm issues Linux laptops to field staff who carry client drawings. The administrator installs each machine with full disk encryption using LUKS2, an Argon2id slot for the employee passphrase, a second slot bound to the laptop’s TPM2 chip with a PIN, and a third slot holding a long recovery passphrase stored in the company password vault. A copy of each header is saved with cryptsetup luksHeaderBackup.

Months later a laptop is stolen from a car. Because it was powered off, the disk contents are unreadable without one of the keys, and the firm documents the loss as an encrypted device incident rather than a data breach. When another employee leaves, the administrator removes that person’s slot with luksKillSlot in a few seconds and reissues the laptop without reinstalling the system.