Disk Encryption (LUKS)

Standard permissions (see File Permissions and Ownership) only matter while the OS is running and enforcing them. Pull the disk out and read it from another machine, and none of that applies - LUKS closes that specific gap by encrypting the data itself, not just controlling access to it through a running system.

What this protects against - and what it doesn't

LUKS protects data at rest: a stolen laptop, a decommissioned drive sent for recycling, a disk pulled from a server. It does not protect a machine that's already booted and unlocked - once the passphrase has been entered and the volume is mounted, the data is plaintext to anything running on that system, same as an unencrypted disk. Encryption at rest and access control while running are separate problems, solved by different tools.

Setting up an encrypted volume

sudo cryptsetup luksFormat /dev/sdb1

WARNING: This will overwrite data on /dev/sdb1 irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase:

This destroys any existing data on the partition and initializes it as a LUKS container - do this on a raw partition (see Disk Partitioning) before anything else is put on it.

sudo cryptsetup luksOpen /dev/sdb1 secure-data

Unlocks the container, prompting for the passphrase, and exposes the decrypted contents as a new device at /dev/mapper/secure-data. From there, treat it like any other block device:

sudo mkfs.ext4 /dev/mapper/secure-data
sudo mount /dev/mapper/secure-data /mnt/secure

sudo umount /mnt/secure
sudo cryptsetup luksClose secure-data

Closing locks it again - without the passphrase, the underlying /dev/sdb1 is unreadable ciphertext.

Checking status

sudo cryptsetup status secure-data
lsblk -o NAME,TYPE,MOUNTPOINT

sdb1                       crypt /mnt/secure
└─secure-data

Unlocking automatically at boot: /etc/crypttab

Manually running luksOpen after every reboot works, but for a volume that should mount automatically, /etc/crypttab pairs with /etc/fstab (see Mounting and fstab) the same way fstab itself lists what to mount:

secure-data  UUID=1a2b3c4d-...  none  luks

With none as the key file, boot will still prompt for the passphrase interactively - genuinely unattended unlocking needs a key file stored somewhere else (a TPM-backed key, or a key on a separate removable device), which trades convenience for a weaker guarantee: anyone with access to that key source can unlock the volume without ever knowing the passphrase.

LUKS with LVM

A common layout on distro installers offering "encrypt my disk": partition, then LUKS on the partition, then LVM (see LVM Basics) inside the decrypted LUKS volume - one passphrase prompt at boot unlocks the LUKS container, and everything built on top of it (root, home, swap as separate logical volumes) becomes available at once.

Back up the LUKS header

The LUKS header (holding the encrypted master key, not your data itself) is small but critical - if it's corrupted, the entire volume becomes permanently unrecoverable, even with the correct passphrase:

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

Store that backup file somewhere separate from the disk itself; it's useless to an attacker without the passphrase, but essential to you if the header on-disk is ever damaged.

Changing or adding a passphrase

LUKS supports multiple key slots, so a second passphrase (or a recovery passphrase kept somewhere safe) can be added without removing the first:

sudo cryptsetup luksAddKey /dev/sdb1
sudo cryptsetup luksRemoveKey /dev/sdb1