Full-disk encryption with LUKS2: how it actually works

Full-disk encryption is the most important single security measure you can apply to a laptop. If your machine is stolen, seized, or forensically imaged while powered off, LUKS2 encryption is what determines whether the data on it is accessible. This article explains in technical detail how LUKS2 actually works — not just what it claims to do, but the specific cryptographic mechanisms that make it function and the precise boundaries of what it protects.

What LUKS2 is and why it replaced LUKS1

LUKS — Linux Unified Key Setup — is the standard disk encryption specification on Linux. LUKS2, released with cryptsetup 2.0 in 2018, replaced the original LUKS1 format with several significant improvements: a more robust header format with redundant storage (the header is written in two locations on disk), support for the Argon2id key derivation function, JSON-based metadata that supports multiple keyslots with individual settings, and better hardware token support.

LUKS1 used PBKDF2 for key derivation, which is vulnerable to GPU-accelerated brute force attacks. LUKS2's adoption of Argon2id addresses this directly.

The encryption stack: from passphrase to data

Understanding LUKS2 means understanding the layered process that transforms your passphrase into access to your data:

• LUKS2 header: stored at the beginning of the encrypted partition. It contains the cipher specification, UUID, JSON metadata, and keyslot data. The header is not encrypted — it's how LUKS knows how to decrypt the rest of the drive. This is important for the header backup discussion below.
• Key derivation function (Argon2id): your passphrase is never used directly as an encryption key. Instead, it is fed through Argon2id, a memory-hard KDF that produces the actual key material. Argon2id is intentionally slow and RAM-intensive — this is by design.
• Key slots: LUKS2 supports up to 32 key slots, each of which can unlock the master key using a different passphrase, hardware key, or recovery key. Each slot independently stores an encrypted copy of the master key. Adding a backup passphrase creates a second slot; the master key itself never changes.
• Master key / volume key: the actual symmetric key used to encrypt all data on the partition. It is generated randomly when you create the LUKS2 container and never changes. Each key slot holds an encrypted copy of this key, unlocked by the slot's own KDF output.
• dm-crypt: the Linux kernel's device mapper crypto target. Once the master key is loaded into kernel memory, dm-crypt presents the encrypted partition as a virtual decrypted block device. The filesystem (ext4, btrfs, etc.) sits on top of this virtual device.

Argon2id: why memory-hard key derivation matters

Argon2id won the Password Hashing Competition in 2015 and is now the recommended KDF for password storage and key derivation by cryptographic standards bodies including OWASP and RFC 9106.

The critical property is that Argon2id is memory-hard: deriving a key requires not just computation but a configurable amount of RAM, and this RAM requirement cannot be traded off for more computation. This makes brute force attacks extremely expensive even with custom ASIC hardware or GPU clusters. An attacker who can try a billion SHA-256 hashes per second might be able to try only a few thousand Argon2id iterations per second with the same hardware, because each iteration requires gigabytes of memory.

The default LUKS2 parameters configure Argon2id to use at least 1 GB of memory and multiple CPU threads per unlock attempt. These parameters are calibrated at setup time based on available hardware — faster hardware results in higher iteration counts, maintaining a target unlock time of roughly 2 seconds on the setup machine.

AES-XTS-plain64: the cipher in practice

LUKS2 defaults to AES-256-XTS, specifically the XTS-plain64 mode. AES-256 is the cipher; XTS (XEX-based Tweaked CodeBook mode with ciphertext Stealing) is the mode of operation designed specifically for disk encryption.

The reason disk encryption uses XTS rather than a mode like CBC or CTR is that disk encryption operates at the sector level. Each 512-byte (or 4096-byte) sector must be encrypted and decrypted independently, without access to adjacent sectors. XTS achieves this by incorporating the sector number as a tweak — a secondary input that makes the encryption of each sector unique even for identical plaintext. This prevents an attacker from detecting repeated blocks of data (the weakness of ECB mode) or from performing specific rearrangement attacks on sectors.

What LUKS2 protects against

LUKS2 full-disk encryption is highly effective against the following threats:

• Physical theft of the drive: a stolen SSD connected to an attacker's system yields nothing without the passphrase. The data is ciphertext.
• Seized machine while powered off: law enforcement or border agents seizing a powered-off laptop with LUKS2 encryption face the same brute force problem as any attacker.
• Forensic imaging: copying the encrypted partition produces an encrypted copy. Without the master key, it's useless.

What LUKS2 does not protect against

LUKS2 has clear limits that are important to understand:

• Running machine: once you've unlocked the drive and booted the system, the master key is in RAM and the filesystem is decrypted and accessible. An attacker with access to a running logged-in machine bypasses encryption entirely.
• Evil Maid attacks: if an attacker has physical access to your machine before you use it, they can replace the bootloader with a malicious version that captures your passphrase when you type it. LUKS2 alone does not prevent this — it requires Secure Boot with a signed bootloader and a UEFI firmware password to protect against boot-level tampering.
• Cold boot attacks: DRAM retains data for seconds to minutes after power is removed, sometimes longer if cooled. An attacker who can physically extract RAM immediately after shutdown may recover key material. This is a sophisticated, targeted attack.
• Key escrow and legal compulsion: LUKS2 provides no plausible deniability. If a court orders you to provide your passphrase, you face legal rather than cryptographic consequences for refusing.

Passphrase guidance: entropy is everything

The strength of your LUKS2 encryption is ultimately limited by the strength of your passphrase. A randomly generated 6-word Diceware passphrase provides approximately 77 bits of entropy. Against Argon2id with LUKS2 default parameters, this represents a brute-force cost that is computationally infeasible for any attacker without a nation-state budget — and likely infeasible even then.

Length beats complexity. A passphrase of five or six random common words is easier to remember and harder to crack than a short string of symbols and numbers. Avoid dictionary words used in natural sentences, personal information, and anything you've used elsewhere.

Backing up the LUKS header

The LUKS header contains the metadata that makes decryption possible. If the header is corrupted — by a failing drive, a botched firmware update, or filesystem error — your data becomes permanently inaccessible, even with the correct passphrase. This is not a theoretical risk; it happens.

Back up the LUKS header using cryptsetup luksHeaderBackup immediately after setting up encryption. Store the backup securely, physically separate from the drive, on an encrypted medium. Treat the header backup with the same care as the passphrase itself — they work together.

Every Norypt Encrypted Laptop ships with LUKS2 full-disk encryption configured with Argon2id, an appropriately set iteration count, and documented header backup instructions — ensuring the setup is correct from the start and recoverable if hardware problems occur.