Full-Disk Encryption Without the Fear

01What LUKS Actually Defends Against

Full-disk encryption gets recommended constantly, but the threat model is narrower than most people assume — and that clarity matters. LUKS, the Linux Unified Key Setup, protects data at rest: when the machine is off, when the drive is yanked, when a laptop goes missing at an airport or a hard drive ends up in a skip. What it does not protect is a running system. Once you have typed your passphrase and the machine has booted, LUKS has done its job; from that point, normal file permissions, user accounts and network exposure govern your security.

What LUKS actually protects against, when it matters, and how to set it up without losing your data.

That scope still covers an enormous amount of real risk. Laptops get stolen. Drives fail and get sent back under warranty. Old SSDs get resold. In every one of those scenarios, an unencrypted drive gives a stranger complete, trivial access to every file, credential, browser session and private key on it. LUKS closes that hole entirely: without the passphrase (or a registered key file), the ciphertext is unreadable.

LUKS2, the current format, uses AES-256 in XTS mode by default — robust, widely audited, and the same standard used in enterprise storage. The key derivation function, Argon2id, is deliberately slow and memory-hard, which blunts brute-force attacks against the passphrase itself.

02Setting It Up: New Installs and Existing Drives

The easiest path is the one with the least risk: enable LUKS during installation. Every major distribution — Ubuntu and its Canonical family, Fedora from Red Hat, openSUSE from SUSE, Debian from the Debian Project, and Arch via the Arch Linux project's own installer guidance — offers a checkbox or guided option at install time. Tick it, choose a strong passphrase, and the installer handles partitioning, the LUKS container, and the boot configuration automatically. There is no reason to avoid this route on a fresh machine.

Encrypting an existing drive in-place is possible but demands respect. cryptsetup reencrypt can encrypt an existing unencrypted drive in place without wiping it, but you must have a current, verified backup before you touch it. A power cut mid-reencrypt without a backup is a data loss event with no recovery path. The command sequence looks roughly like this, with /dev/sdX standing in for your unmounted partition: cryptsetup reencrypt --encrypt --init-only --reduce-device-size 32M /dev/sdX cryptsetup reencrypt --resume-only /dev/sdX

# Back up first. Seriously.
sudo cryptsetup reencrypt --encrypt --init-only /dev/sdXY
sudo cryptsetup reencrypt /dev/sdXY

The --init-only flag writes the LUKS header before the long reencryption pass begins, which means an interrupted run is recoverable. Even so, a fresh install is the safer and simpler choice for most people.

03Passphrases, Key Files, and TPM Unlock

A LUKS volume can hold up to thirty-two key slots, each holding an independent way to unlock it. That means you can have a strong passphrase for manual recovery and a key file stored on a USB token for convenience — losing either one does not lock you out.

TPM-based automatic unlock is increasingly common on Fedora (via systemd-cryptenroll) and openSUSE, where the drive key is sealed to the TPM chip and released without a prompt at boot, while still staying encrypted against physical removal. This feels like magic but has a real caveat: it protects the drive outside the machine, not inside it. Anyone who can boot that specific hardware gets in without a passphrase. Whether that trade-off suits you depends on your threat model.

For most personal machines, a single strong passphrase — long, memorable, unique — is the right answer. Store it somewhere offline: a paper note in a safe place, a hardware password manager. LUKS cannot help you if you forget the passphrase and have no backup key slot; there is no reset mechanism, by design.

Switch it on at install time, back up the LUKS header with cryptsetup luksHeaderBackup, and the hard problem is largely solved.