Encrypting Your Linux Installation with LUKS

Encrypting Your Linux Installation with LUKS

By How we write our guides

Encrypting your Linux installation means that if someone gets physical access to your drive — by stealing your laptop, pulling the drive from a powered-off machine, or booting a live OS from USB — they cannot read any of your data. This is especially important for laptops and any machine that travels.

How LUKS encryption works

LUKS operates at the block device level, below the filesystem. The structure is:

Physical disk: /dev/sda2
        |
        v
LUKS container (encrypted block device)
  - LUKS header at start of partition (stores encryption metadata)
  - Key slots (1-8): each holds a copy of the master key, encrypted
    with a passphrase using PBKDF2 or Argon2 key derivation
        |
        v  (after unlocking with passphrase)
dm-crypt virtual device: /dev/mapper/cryptroot
  (decrypted view of the partition, exists only while unlocked)
        |
        v
Filesystem (ext4 / btrfs / xfs) mounted from /dev/mapper/cryptroot

All data written to the filesystem is encrypted as it goes to the physical partition. All data read is decrypted transparently. The passphrase never directly encrypts your data; it encrypts the master key stored in the LUKS header.

Enabling encryption during installation

Ubuntu installer

On the disk setup screen:

  1. Select “Erase disk and install Ubuntu”
  2. Check “Encrypt the new Ubuntu installation for security”
  3. Set a strong passphrase (write it down or store it in a password manager)
  4. Check “Use LVM with the new Ubuntu installation” (recommended alongside encryption for flexible partition management)

The installer creates:

/dev/sda1   512MB   FAT32    /boot/efi     (unencrypted: UEFI needs to read this)
/dev/sda2   1GB     ext4     /boot         (unencrypted: kernel and initramfs)
/dev/sda3   ~rest   LUKS     [encrypted]
  /dev/mapper/sda3_crypt -> LVM
    /dev/ubuntu-vg/ubuntu-lv  ext4  /      (encrypted root)
    swap                      swap         (encrypted swap)

The /boot partition and EFI partition are unencrypted because the bootloader runs before the LUKS passphrase is entered and cannot read encrypted data.

Fedora installer (Anaconda)

In the storage configuration screen:

  1. Select “Custom” storage
  2. Check “Encrypt my data” at the bottom
  3. Set a passphrase
  4. Click “Done” and create partitions in the next screen
  5. The installer creates a LUKS container and puts LVM logical volumes inside it

Arch Linux (manual)

# After partitioning (e.g., sda1=EFI, sda2=boot, sda3=root):

# Create the LUKS container
cryptsetup luksFormat --type luks2 /dev/sda3
# WARNING: This will overwrite data on /dev/sda3 irrevocably.
# Are you sure? (Type uppercase yes): YES
# Enter passphrase: [your passphrase]
# Verify passphrase: [again]

# Open (unlock) the LUKS container
cryptsetup luksOpen /dev/sda3 cryptroot
# The unlocked container is now at /dev/mapper/cryptroot

# Create the filesystem on the unlocked container
mkfs.ext4 /dev/mapper/cryptroot

# Mount and proceed with installation
mount /dev/mapper/cryptroot /mnt
mount /dev/sda1 /mnt/boot/efi   # EFI partition
# ... continue with pacstrap, genfstab, chroot ...

# Configure mkinitcpio to include the encrypt hook
nano /etc/mkinitcpio.conf
# HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block encrypt lvm2 filesystems fsck)

# Get the UUID of the LUKS partition
blkid /dev/sda3
# /dev/sda3: UUID="xxxx-xxxx-..." TYPE="crypto_LUKS"

# Configure the bootloader (GRUB) to pass the encrypted device
nano /etc/default/grub
# GRUB_CMDLINE_LINUX="cryptdevice=UUID=xxxx-xxxx-...:cryptroot root=/dev/mapper/cryptroot"

grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -P

What encryption looks like at boot

With a LUKS-encrypted root partition, the boot sequence adds one step:

UEFI firmware
    |
    v
GRUB (from /boot/efi, unencrypted)
    |
    v
Linux kernel + initramfs (from /boot, unencrypted)
    |
    v
initramfs prompts: "Please unlock disk /dev/sda3 (cryptroot):"
[you enter your passphrase]
    |
    v
dm-crypt unlocks the LUKS container
/dev/mapper/cryptroot becomes available
    |
    v
Root filesystem mounts from /dev/mapper/cryptroot
Normal boot continues

The passphrase prompt appears before the login screen, before the desktop environment loads, and before any user processes start.

Managing LUKS after installation

Inspect a LUKS device

# Show LUKS header information
sudo cryptsetup luksDump /dev/sda3
# Version:        2
# Epoch:          3
# Metadata area:  16384 [bytes]
# Keyslots area:  16744448 [bytes]
# UUID:           xxxx-xxxx-...
# Algorithm:      aes
# IV generator:   random
# Integrity:      hmac-sha256
# ...
# Keyslots:
#   0: luks2
#      Key:        512 bits
#      ...

# Check if a device is LUKS
sudo cryptsetup isLuks /dev/sda3 && echo "LUKS" || echo "Not LUKS"

# Show dm-crypt active mappings
ls /dev/mapper/
sudo dmsetup ls --target crypt

Add a second passphrase (backup key)

# LUKS supports up to 8 key slots
# Add a second passphrase to slot 1
sudo cryptsetup luksAddKey /dev/sda3
# Enter any existing passphrase: [existing passphrase]
# Enter new passphrase for key slot: [backup passphrase]
# Verify passphrase: [backup passphrase again]

# Verify both slots are in use
sudo cryptsetup luksDump /dev/sda3 | grep -A2 "Keyslots:"

Add a key file (for automating secondary encrypted drives)

# Create a random key file
sudo dd if=/dev/urandom of=/root/secondary-drive.key bs=4096 count=1
sudo chmod 400 /root/secondary-drive.key

# Add the key file as a LUKS key
sudo cryptsetup luksAddKey /dev/sdb1 /root/secondary-drive.key
# Enter existing passphrase to unlock: [your passphrase]

# Configure /etc/crypttab to auto-unlock at boot using the key file
# UUID of /dev/sdb1 (get with: sudo blkid /dev/sdb1)
echo "data_drive UUID=xxxx /root/secondary-drive.key luks" | sudo tee -a /etc/crypttab

# /dev/mapper/data_drive will then be available after boot
# Add to /etc/fstab to auto-mount:
# /dev/mapper/data_drive  /mnt/data  ext4  defaults  0  2

Change a passphrase

# Change the passphrase in key slot 0
sudo cryptsetup luksChangeKey /dev/sda3
# Enter passphrase to be changed: [old passphrase]
# Enter new passphrase: [new passphrase]
# Verify passphrase: [new passphrase]

Remove a key slot

# Remove key slot 1 (only if you still have another slot that works)
# Verify slot 0 still unlocks the volume first:
sudo cryptsetup open --test-passphrase /dev/sda3

# Then remove slot 1
sudo cryptsetup luksKillSlot /dev/sda3 1
# Enter any remaining passphrase: [slot 0 passphrase]

Back up the LUKS header

The LUKS header contains the encryption metadata. If the header is corrupted (disk damage, accidental overwrite), the data is permanently unrecoverable even with the correct passphrase.

# Back up the LUKS header to a file
sudo cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file luks-header-backup.img

# Store this file somewhere safe and separate from the encrypted drive
# An external drive, USB stick, or encrypted cloud storage

# Restore header from backup (only if header is corrupted)
sudo cryptsetup luksHeaderRestore /dev/sda3 --header-backup-file luks-header-backup.img

Performance check

# Verify AES-NI hardware acceleration is available
grep -m1 -o 'aes' /proc/cpuinfo
# aes (means AES-NI is present)

# Benchmark encryption performance
sudo cryptsetup benchmark
# Tests different cipher/key combinations
# With AES-NI, you should see 1-5 GB/s for aes-xts:
# aes-xts   256b   3.1 GiB/s  enc  3.2 GiB/s  dec

# Compare this to your SSD speed:
sudo hdparm -tT /dev/sda
# Likely 500MB/s - 3500MB/s for typical SSDs
# AES-NI encryption is faster than the disk, so no bottleneck

/etc/crypttab and /etc/fstab

The system uses /etc/crypttab to know which LUKS devices to unlock at boot and /etc/fstab to know where to mount the unlocked filesystems.

cat /etc/crypttab
# cryptroot UUID=xxxx-xxxx-...  none  luks

# Fields:
# Name (what /dev/mapper/NAME will be created)
# UUID of the LUKS partition (or device path)
# Key file path (none = prompt at boot)
# Options (luks, discard for SSDs, etc.)

cat /etc/fstab
# /dev/mapper/cryptroot  /  ext4  errors=remount-ro  0  1

# For SSDs: enabling discard improves performance (TRIM support)
# In /etc/crypttab: add "luks,discard" to options
# cryptroot UUID=...  none  luks,discard

Frequently Asked Questions

What is LUKS and how does it work?

LUKS (Linux Unified Key Setup) is the standard for disk encryption on Linux. It operates at the block device level: LUKS encrypts an entire partition, and the filesystem (ext4, btrfs, etc.) is created inside the encrypted container. When the system boots, the bootloader loads the kernel and initramfs from an unencrypted /boot partition, then prompts for a passphrase to unlock the LUKS container. Once unlocked, dm-crypt (the kernel device mapper encryption module) creates a virtual block device (e.g., /dev/mapper/cryptroot) that looks and behaves like a regular unencrypted partition, and the filesystem is mounted from it. All reads and writes are transparently encrypted and decrypted in memory. The encryption key is derived from your passphrase using a key derivation function (PBKDF2 or Argon2).

Should I encrypt my Linux installation?

Yes, if the machine ever leaves your home or office, or if the disk could be physically accessed by someone else. Encryption protects all your data — documents, browser history, saved passwords, SSH keys, code, emails — if the laptop is lost, stolen, or seized. Without encryption, anyone who boots a live USB on your machine can read every file. With encryption, they get unreadable ciphertext without your passphrase. The performance cost of encryption on modern hardware is minimal: AES-NI hardware acceleration means encryption adds less than 1-2% overhead on most workloads. The main trade-off is that forgetting your passphrase means permanent data loss; there is no recovery without a backup of the LUKS header or key.

How do I enable encryption during installation?

In the Ubuntu installer: on the disk setup screen, select “Erase disk and install Ubuntu,” then check the “Encrypt the new Ubuntu installation for security” checkbox. Set a strong passphrase when prompted. The installer handles the rest: creates an encrypted LUKS container, creates a filesystem inside it, and configures the boot process to prompt for the passphrase at startup. In Fedora/Anaconda: select Custom storage, then check “Encrypt my data” at the bottom of the storage screen before creating partitions. In Arch Linux (manual): run cryptsetup luksFormat /dev/sda2 to create the LUKS container, then cryptsetup luksOpen /dev/sda2 cryptroot to unlock it, then create your filesystem on /dev/mapper/cryptroot.

What happens if I forget my encryption passphrase?

If you forget your LUKS passphrase and have not created any backup keys or a LUKS header backup, the encrypted data is permanently inaccessible. LUKS is designed to be strong enough that brute-forcing the passphrase is infeasible for a strong passphrase. There is no backdoor, no recovery mode, and no way to reset the passphrase without the original. This is both the point (your data is secure from attackers) and the risk (you can lock yourself out). Mitigations: add a second passphrase in a different LUKS key slot (cryptsetup luksAddKey) as a backup; store a recovery key in a secure offline location; back up the LUKS header with cryptsetup luksHeaderBackup to external storage.

Does encryption slow down Linux significantly?

On any CPU with AES-NI hardware acceleration (all Intel CPUs since Westmere 2010, all AMD CPUs since Bulldozer 2011), the overhead of LUKS encryption with AES-XTS is under 2% for typical workloads. A system that reads files, browses the web, writes documents, or runs code will not notice a meaningful performance difference with LUKS enabled. Workloads that are heavily disk-bound (reading or writing large files continuously at the drive’s maximum throughput) see slightly more overhead, but even here the difference is small on modern SSDs where the CPU can encrypt data faster than the NVMe drive can store it. You can verify AES-NI is present with: grep -m1 -o aes /proc/cpuinfo.

How do I add a second unlock key to my LUKS partition?

LUKS supports up to 8 key slots, each of which can unlock the encryption. Add a second passphrase: sudo cryptsetup luksAddKey /dev/sda2 (you will be prompted for the existing passphrase first, then the new one). Add a key file (useful for auto-unlock of a secondary encrypted partition): dd if=/dev/urandom of=/root/keyfile bs=4096 count=1, chmod 400 /root/keyfile, sudo cryptsetup luksAddKey /dev/sda2 /root/keyfile. To see how many slots are in use: sudo cryptsetup luksDump /dev/sda2 | grep “Key Slot”. To remove a key slot: sudo cryptsetup luksKillSlot /dev/sda2 slot-number. Never remove a key slot without verifying that another slot still unlocks the volume.

Related articles

Unlock LUKS With the TPM: systemd-cryptenroll ExplainedBind your encrypted disk to the TPM so it unlocks automatically at boot, or with a short PIN, and only on your untouched machine. How TPM sealing and PCRs work, the exact enrollment steps, recovery keys, and the security trade-offs.LUKS Disk Encryption: Setting Up and Managing Encrypted VolumesFull disk encryption protects data at rest, which means a stolen laptop or a returned disk. Here is how key slots work, how to add and revoke passphrases, and what LUKS does not protect against.Securely Wiping Drives on Linux: shred, SSD Secure Erase, and NVMe SanitizeWhy shred works on hard drives but not SSDs, how to wipe a whole HDD, how to use ATA secure erase and NVMe format or sanitize to erase SSDs properly, and why encryption plus key destruction is the most reliable approach.