Why Encrypt at Rest

Device theft is not a hypothetical. Laptops are left on trains. Phones are dropped in taxis. Servers are decommissioned and their hard drives sold, donated, or discarded — often with data intact. A 2019 study by Blancco found that 42% of second-hand drives purchased on eBay contained recoverable data, including personally identifiable information and corporate documents. The sellers believed the data had been deleted. It had not.

Border seizure is another vector. Customs officials in some jurisdictions — the United States, the United Kingdom, Canada, Australia, among others — have the authority to inspect electronic devices at the border. In some cases, they can compel you to unlock the device or image its contents. The legal frameworks vary, but the technical reality is consistent — without encryption, physical access to the storage medium is total access to the data.

Decommissioning is the quieter risk. Hard drives returned under warranty. Recycled machines donated to schools or charities. Backup tapes sent to offsite storage facilities staffed by people you have never met. Every device that leaves your physical control with unencrypted data on it is a potential data breach waiting for someone curious or motivated enough to look.

Without encryption, anyone who obtains the physical storage media — by theft, by seizure, by purchase, by dumpster diving — has every file, every credential, every email, every SSH key, every browser session cookie. LUKS eliminates that exposure entirely.

What LUKS Is

LUKS — Linux Unified Key Setup — is the standard front-end to dm-crypt, the Linux kernel's block-level encryption subsystem. It creates an encrypted container on a partition or block device, stores key metadata in a standardised header, and decrypts the data transparently after you provide the passphrase at boot.

The encryption is AES-256-XTS by default — the same algorithm and key length specified for government classified systems. The XTS mode is designed specifically for storage encryption, handling the unique challenges of encrypting data at rest — sectors that can be read and written independently, without the chaining dependencies of modes like CBC that would make random access to the disc prohibitively slow.

LUKS does not encrypt individual files. It encrypts the entire block device — every file, every directory, every byte of free space, every deleted file that has not yet been overwritten, every log entry, every swap page. This is full-disc encryption — or more precisely, full-partition encryption. Nothing on the encrypted partition is readable without the key. There are no gaps, no excluded directories, no partial coverage.

Encryption During Ubuntu Installation

The simplest and most reliable path to LUKS is during installation. The Ubuntu installer — both the legacy Ubiquity installer for Desktop and the newer Subiquity installer for Server — offers "Encrypt the new Ubuntu installation" as a checkbox during the partitioning step.

Selecting this option creates an LVM-on-LUKS layout. The installer partitions the drive into a small unencrypted /boot partition — required for GRUB to load the kernel and initramfs before the encrypted volume is available — and a single large LUKS container occupying the remainder of the disc. Inside that LUKS container, LVM — the Logical Volume Manager — creates logical volumes for the root filesystem and swap space.

The installer prompts for an encryption passphrase. Choose carefully. This passphrase is the single point of failure between physical access and total data exposure.

It should be long — twenty characters or more. It should be memorable — you will type it at every boot, potentially every day for years. It should not be reused from any other system, service, or account. A passphrase of four or five truly random words — the approach popularised by Randall Munroe's "correct horse battery staple" illustration — is both cryptographically strong and practical for daily use.

The installer handles everything else — partitioning the disc, formatting the LUKS container, creating the LVM volume group and logical volumes, formatting the filesystems, installing GRUB with LUKS support, and configuring the crypttab and fstab entries. Reboot, type your passphrase at the LUKS prompt, and the system starts normally.

LUKS on an Existing System

Encrypting an existing, running system in place is technically possible. It is also complex, error-prone, and one miscalculated offset away from total data loss. The process involves shrinking the filesystem to create space for the LUKS header, encrypting the partition in place using cryptsetup-reencrypt, and then expanding the filesystem back — all while ensuring the boot configuration, initramfs, and crypttab are correctly updated to reflect the new layout.

Do not attempt it unless you have no alternative. The recommended approach is simpler and substantially safer — back up everything to an external medium, reinstall Ubuntu with the encryption checkbox selected, and restore your data and configuration from the backup. The time spent on a clean reinstall is less than the time spent recovering from a failed in-place encryption attempt. And the recovery from a failed attempt may not be possible at all.

Key Management

LUKS supports up to eight key slots. Each slot holds a copy of the volume's master key, encrypted with a different passphrase. The master key itself is randomly generated during LUKS formatting and never changes — the passphrases in each slot are independent wrappers around it. Changing a passphrase does not change the master key. Adding a passphrase does not weaken the encryption.

This design enables a critical operational practice — the recovery key. Add a second passphrase to a separate key slot:

sudo cryptsetup luksAddKey /dev/sda3

The command prompts for an existing passphrase — to prove you currently have authorised access — and then for the new passphrase to store in the next available slot. Use a long, randomly generated string for the recovery key — openssl rand -base64 48 produces a suitable one. Do not try to memorise it. Print it. Seal the printout in an envelope. Store the envelope in a physical safe — at a different location from the machine. Label it clearly.

This is your recovery key. If you forget your daily passphrase, if the keyboard layout changes and you cannot type it correctly, if you are incapacitated and someone else needs to access the machine — the recovery key is the fallback.

To see which key slots are occupied:

sudo cryptsetup luksDump /dev/sda3

The output lists all eight slots, each marked as ENABLED or DISABLED. A prudent configuration uses slot 0 for your daily passphrase and slot 1 for the offline recovery key. The remaining six slots are available for temporary access — granting a colleague the ability to boot the machine while you are travelling, then revoking that access on your return with cryptsetup luksRemoveKey.

Header Backup

The LUKS header IS the encryption. It contains the encrypted copies of the master key, the key slot metadata, the cipher specification, and the hash algorithm configuration. If the header is destroyed — by a disc error in the first two megabytes, a careless dd command that overwrites the beginning of the partition, a zeroed first few sectors, or filesystem corruption that reaches the header area — the data is irrecoverable. Not difficult to recover. Not expensive to recover. Irrecoverable. The passphrase alone is useless without the header's master key material to decrypt.

Back up the header:

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

The backup file is small — typically two to four megabytes. Store it offline, in a different physical location from the machine. Treat it exactly like a key — because it is one. Anyone who possesses the header backup file and knows any one of the valid passphrases can decrypt the entire drive, even if the original drive's header has been modified, overwritten, or destroyed.

Update the header backup whenever you add or remove key slots. An outdated header backup will not contain passphrases added after the backup was taken.

Performance

The performance concern is a relic of the era before hardware acceleration. Modern x86 CPUs — Intel since Westmere in 2010, AMD since Bulldozer in 2011 — include AES-NI, dedicated hardware instructions for AES encryption and decryption. ARM processors in modern servers and laptops include equivalent cryptographic extensions.

With AES-NI, the throughput overhead of LUKS encryption is negligible — single-digit percentages on most workloads, often within measurement noise on a well-configured system. Sequential read and write throughput is virtually unchanged. Random I/O sees marginally more impact due to the per-sector encryption computation, but the effect remains small relative to the I/O latency of the storage device itself.

Benchmark your specific hardware:

sudo cryptsetup benchmark

This tests various cipher and key size combinations. On a modern CPU with AES-NI enabled, expect AES-XTS throughput figures measured in multiple gigabytes per second — well above what any single SSD can deliver. The encryption layer is not the bottleneck. The storage device is.

SSD Considerations

TRIM — the command that tells an SSD which blocks are no longer in use, allowing the drive's controller to reclaim them for wear levelling and garbage collection — presents a tension with full-disc encryption. By default, LUKS does not pass TRIM commands through the encryption layer. This is the conservative, security-first default — TRIM reveals which blocks on the underlying device contain active data and which are free, leaking the filesystem's block allocation pattern through the encryption.

For most threat models, the trade-off favours enabling TRIM. The information leaked — the pattern of used and unused blocks, not the content of those blocks — is of limited practical value to an attacker who already has physical possession of the drive. Without TRIM, the SSD cannot perform its internal garbage collection and wear levelling efficiently, leading to write amplification, degraded write performance over time, and reduced drive lifespan.

Enable TRIM by adding the discard option to the crypttab entry. Edit /etc/crypttab:

sda3_crypt UUID=your-uuid-here none luks,discard

After editing, update the initramfs to include the new configuration:

sudo update-initramfs -u

The discard option is a per-device, per-threat-model decision. For a laptop used by an individual with a standard threat model — theft, loss, border inspection — enable it. The performance and longevity benefits outweigh the marginal information leakage. For a machine storing highly sensitive data where the threat model specifically includes forensic analysis of block allocation patterns by a well-resourced adversary, leave it disabled and accept the performance trade-off.

Remote Unlock for Servers

A headless server with LUKS presents a practical problem — someone must type the passphrase at the console during boot. If the server reboots at 03:00 after a kernel update, an unattended reboot, or a power event, it sits at the LUKS passphrase prompt until a human intervenes. For a server in a rack you can physically reach, this is an inconvenience. For a remote server in a datacentre hundreds of miles away, it is a significant operational risk — potentially hours of downtime while you arrange console access.

Dropbear-initramfs solves this. It embeds a lightweight SSH server — Dropbear — into the initramfs, the minimal filesystem loaded before the root partition is decrypted. The server boots, configures its network interface via DHCP or a static address, starts the Dropbear SSH daemon, and waits. You SSH in during this early boot phase and provide the LUKS passphrase. Decryption proceeds. Boot continues normally.

Install and configure:

sudo apt install dropbear-initramfs

Add your SSH public key to the Dropbear authorised keys file:

sudo cp ~/.ssh/authorized_keys /etc/dropbear/initramfs/authorized_keys

Update the initramfs to include the Dropbear binary and configuration:

sudo update-initramfs -u

On the next reboot, the server reaches the LUKS passphrase prompt and simultaneously starts Dropbear on port 22. From your workstation, connect:

ssh root@server-ip

At the Dropbear shell, unlock the encrypted volume:

cryptroot-unlock

Type the passphrase. The server decrypts the root volume, pivots from the initramfs to the real root filesystem, and continues booting normally. Dropbear stops — the regular OpenSSH daemon takes over once the full system is running. Note that Dropbear and OpenSSH use different host keys — your SSH client may warn about a changed host key depending on which stage of boot you are connecting to. Store both fingerprints and verify them.

The Legal Position

In the United Kingdom, Part III of the Regulation of Investigatory Powers Act 2000 — RIPA — grants authorities the power to compel disclosure of encryption keys or the plaintext they protect. A notice under section 49 requires you to hand over the key or decrypt the data. Refusal is a criminal offence under section 53. The penalty is up to two years' imprisonment, rising to five years in cases involving national security or child indecency.

Other jurisdictions have comparable provisions. Australia's Assistance and Access Act 2018 includes technical capability notices. France's Article 434-15-2 of the Penal Code penalises refusal to provide a cryptographic key when ordered by judicial authority. The United States' position is less settled — the Fifth Amendment's protection against self-incrimination has been applied inconsistently to compelled decryption, and the outcome depends on whether the government can demonstrate with "reasonable particularity" what the encrypted data contains.

This is not advice to avoid encryption — encryption remains an essential security control and is often a regulatory requirement under GDPR, PCI DSS, HIPAA, and other frameworks. It is context you should understand before you travel internationally with an encrypted device, store encrypted data in an unfamiliar jurisdiction, or face a lawful request for access.

Verifying Encryption

Confirm your system is encrypted and identify the active configuration:

lsblk

Look for a crypt entry in the TYPE column — this is the device mapper layer created by LUKS.

sudo cryptsetup status sda3_crypt

This shows the active mapping — the cipher in use, the key size, the underlying device, and the data offset.

sudo dmsetup table --showkeys sda3_crypt

This displays the full device mapper table, including the cipher specification. On a standard Ubuntu LUKS installation, expect aes-xts-plain64 with a 512-bit combined key — AES-XTS uses 256 bits for encryption and 256 bits for the XTS tweak value, reported as a single 512-bit key.

Enable LUKS encryption during Ubuntu installation rather than attempting in-place encryption afterwards, add a recovery key to a second key slot and store the printout in a physical safe at a different location from the machine, back up the LUKS header immediately and again after every key slot change, enable TRIM for SSDs unless your specific threat model excludes it, install Dropbear-initramfs on any headless server to enable remote passphrase entry during boot, and familiarise yourself with the legal framework around compelled key disclosure in every jurisdiction where your encrypted devices will operate.