LUKS encrypts a block device so that its contents are unreadable without a passphrase. What it protects is data at rest, and being precise about that is important.

What it does and does not do

Protects against: a stolen laptop, a disk sold or returned with data still on it, a drive pulled from a decommissioned server, someone with physical access to powered-off hardware.

Does not protect against: anything once the volume is unlocked. Malware on a running system, someone using your unlocked session, or a compromised process all see plaintext, because the kernel is decrypting transparently.

Full disk encryption is genuinely valuable and it is not a general security measure. It answers one specific question.

The key slot design

This is the part worth understanding, because it explains everything else.

The data is encrypted with a master key that is generated once and never changes. That master key is itself stored in the LUKS header, encrypted separately in each of up to eight key slots, each unlocked by a different passphrase or key file.

Two consequences follow:

Changing a passphrase is instant. It rewrites one small slot rather than re-encrypting terabytes.

The header is critical. Lose or damage it and the master key is gone, and no passphrase can recover the data. There is no backdoor and no recovery service.

Setting up a volume

# Format. This destroys everything on the device.
sudo cryptsetup luksFormat /dev/sdb1

# Open it, creating /dev/mapper/mydata
sudo cryptsetup open /dev/sdb1 mydata

# Put a filesystem on the mapped device, not the raw one
sudo mkfs.ext4 /dev/mapper/mydata
sudo mount /dev/mapper/mydata /mnt/data

# Later
sudo umount /mnt/data
sudo cryptsetup close mydata

For a root filesystem, use your distribution’s installer, which handles the initramfs integration needed to prompt for the passphrase before the system boots.

Back up the header, now

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file luks-header.img

It is a small file. Store it somewhere separate from the disk, and treat it as sensitive, because it contains the encrypted master key and someone with it and your passphrase has your data.

Restoring:

sudo cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file luks-header.img

Note that restoring an old header re-enables any passphrase that was valid when it was taken, including ones you revoked since. That is a real consideration if you removed someone’s access.

Managing passphrases

sudo cryptsetup luksDump /dev/sdb1              # which slots are in use
sudo cryptsetup luksAddKey /dev/sdb1            # add a passphrase
sudo cryptsetup luksChangeKey /dev/sdb1         # change one
sudo cryptsetup luksKillSlot /dev/sdb1 1        # revoke slot 1

The pattern worth adopting: one passphrase you type daily, and one long recovery passphrase in a password manager or on paper in a safe. If you forget the daily one, the recovery one still works.

Key files, for unattended unlocking

sudo dd if=/dev/urandom of=/root/backup.key bs=512 count=8
sudo chmod 400 /root/backup.key
sudo cryptsetup luksAddKey /dev/sdb1 /root/backup.key

Then in /etc/crypttab:

backupdisk  UUID=xxxx-xxxx  /root/backup.key  luks

This unlocks a secondary disk automatically at boot. Note the obvious limitation: the key file is on an unencrypted root, or on a root that someone unlocked. It removes a prompt; it does not add protection to the machine as a whole.

TPM unlocking

sudo systemd-cryptenroll --tpm2-device=auto /dev/sdb1

Binds the key to TPM state so the volume unlocks without a passphrase, provided the boot chain has not changed.

The tradeoff is explicit: anyone who can power on the machine gets the data. That is fine for a server in a locked rack and a poor choice for a laptop that gets carried around, unless combined with Secure Boot and a firmware password.

Performance

Negligible on any CPU with AES-NI, which is essentially everything from the last decade.

cryptsetup benchmark
grep -o 'aes\|sha_ni' /proc/cpuinfo | sort -u

The default cipher is aes-xts-plain64, which is the right choice and worth leaving alone.

Frequently Asked Questions

What does LUKS actually protect against?

Data at rest. A stolen laptop, a disk returned under warranty, or a drive pulled from a decommissioned machine. It does nothing once the volume is unlocked and the system is running, so it is not protection against malware or someone using your logged-in session.

What are LUKS key slots?

Up to eight independent slots, each holding the master key encrypted with a different passphrase or key file. Any one of them unlocks the volume, which is how you give several people access or keep a recovery passphrase separate from your daily one.

Can I change my passphrase without re-encrypting?

Yes, and that is the point of the key slot design. The master key never changes, so adding or removing a passphrase only rewrites a small header slot rather than touching the data.

What happens if the LUKS header is damaged?

The volume becomes permanently unrecoverable, because the master key lives in the header and there is no way to derive it from the passphrase alone. Back up the header separately; it is a small file and it is the difference between a recoverable and an unrecoverable disk.

Does encryption slow the system down?

Barely, on any CPU with AES-NI hardware acceleration, which is essentially everything modern. The overhead is measurable in benchmarks and rarely noticeable in use. Older hardware without acceleration is a different matter.

Can I unlock automatically with a TPM?

Yes, using systemd-cryptenroll to bind the key to TPM state. That removes the boot passphrase and means anyone who can boot the machine gets the data, so it is a convenience and security tradeoff rather than a free win.