How to Set Up Full-Disk Encryption on Linux with LUKS

LUKS (Linux Unified Key Setup) is the standard disk-encryption format on Linux, handling the key management and header format so tools and distributions can interoperate rather than each inventing their own encryption scheme.

Step 1: install the required tools

sudo apt install cryptsetup      # Debian/Ubuntu
sudo dnf install cryptsetup      # Fedora/RHEL

Step 2: initialize LUKS encryption on the target device

sudo cryptsetup luksFormat /dev/sdb1

This destroys any existing data on the target partition — confirm you’re targeting the correct device before confirming, since there’s no undo. You’ll be prompted to set a passphrase, which becomes the key protecting access to the encrypted volume.

Step 3: open the encrypted volume

sudo cryptsetup luksOpen /dev/sdb1 mydata

This prompts for the passphrase set in Step 2, and creates a decrypted device mapping at /dev/mapper/mydata — a virtual block device that transparently encrypts/decrypts as it’s used.

Step 4: format the decrypted device with a filesystem

sudo mkfs.ext4 /dev/mapper/mydata

Note this formats the decrypted mapping, not the raw underlying partition — the filesystem itself has no idea it’s sitting on top of encryption.

Step 5: mount and use it normally

sudo mkdir /mnt/mydata
sudo mount /dev/mapper/mydata /mnt/mydata

Step 6: close the encrypted volume when done

sudo umount /mnt/mydata
sudo cryptsetup luksClose mydata

Once closed, the underlying partition is just encrypted, unreadable data — the passphrase is required again to open it.

Step 7: add a backup key slot, in case the primary passphrase is lost

sudo cryptsetup luksAddKey /dev/sdb1

LUKS supports multiple independent passphrases (key slots) for the same volume — adding a second one (perhaps stored securely elsewhere) is cheap insurance against losing access if the primary passphrase is forgotten.

Step 8: set up automatic unlocking at boot with a key file (optional)

sudo dd if=/dev/urandom of=/root/mydata.key bs=1024 count=4
sudo chmod 600 /root/mydata.key
sudo cryptsetup luksAddKey /dev/sdb1 /root/mydata.key

# /etc/crypttab
mydata  /dev/sdb1  /root/mydata.key  luks

This trades entering a passphrase manually at every boot for automatic unlocking via a key file — appropriate for a server that needs to boot unattended, though it means anyone with access to that key file (and the disk) can decrypt the data, so the key file’s own access permissions matter enormously.

Step 9: add the entry to fstab for automatic mounting

# /etc/fstab
/dev/mapper/mydata  /mnt/mydata  ext4  defaults  0  2

Why LUKS specifically, rather than encrypting at the filesystem level

LUKS encrypts at the block device level, below the filesystem entirely — meaning the filesystem, and everything above it, has no encryption-awareness at all and just works normally against what looks like an ordinary decrypted block device. This is a meaningfully different, often simpler security model than filesystem-level encryption (which requires filesystem support and can leave certain metadata unencrypted), at the cost of encrypting the entire volume as one unit rather than being able to select individual files or directories for encryption.

LUKS2 versus the older LUKS1 format

Current cryptsetup defaults to LUKS2, a substantial revision over the original LUKS1 format that added a more flexible, JSON-based metadata area, a configurable key-derivation function (Argon2id by default, replacing LUKS1’s fixed PBKDF2), and redundant metadata storage for better resilience against header corruption. Argon2id specifically is a memory-hard function, meaning it’s deliberately expensive to accelerate with GPUs or dedicated cracking hardware in a way PBKDF2 no longer resists as well against modern attack hardware — a real security improvement for passphrase-protected volumes, not just a metadata format change. LUKS1 remains available (cryptsetup luksFormat --type luks1) specifically for compatibility with older bootloaders or systems that don’t yet understand LUKS2, but a new volume with no such constraint should use the LUKS2 default rather than deliberately opting into the older format.

Unlocking automatically with a TPM instead of a plaintext key file

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

The key-file approach in Step 8 above has a real weakness: the key file itself is plaintext on disk, and anyone who can read it (and access the encrypted disk) can decrypt the volume — automatic unlocking and genuine security are somewhat in tension. systemd-cryptenroll offers a meaningfully stronger alternative on hardware with a TPM2 chip: it seals a LUKS key inside the TPM itself, bound to the system’s current boot measurements (specific PCR values reflecting firmware, bootloader, and kernel state), so the TPM only releases the key when those measurements match an unmodified boot chain. This gets you the same unattended-boot convenience as a key file, but the key is never present as a readable file anywhere on disk — extracting it requires either the physical TPM chip or successfully tampering with boot in a way that changes the measured state enough to make the TPM refuse to release it, a meaningfully higher bar than reading a file with the wrong permissions. Keeping the original passphrase enrolled as a fallback key slot alongside the TPM enrollment is worth doing regardless, since replacing a motherboard or updating firmware in a way that shifts the measured PCR values can leave the TPM unable to release its sealed key even though nothing malicious happened at all.

Related:

Sources: