Encrypted Filesystems with LUKS (cryptsetup)

LUKS (Linux Unified Key Setup) is the standard way to encrypt a block device on Linux. It sits on two pieces: dm-crypt, the kernel device-mapper target that transparently encrypts and decrypts every block as it's written and read, and the LUKS header, an on-disk metadata area that stores the cipher choice and the key slots. What it protects is data at rest: pull the disk, image it, or steal the laptop, and without the passphrase the bytes are noise. What it does not protect is a running, unlocked system — once the volume is open, the filesystem is plaintext to anyone with access, exactly like any other mount.

The key detail that trips people up: LUKS does not encrypt your data with your passphrase. The disk is encrypted with a random master key, generated once at format time. Your passphrase unlocks a key slot that holds an encrypted copy of that master key. That indirection is why you can have up to eight passphrases for one volume, change a passphrase without re-encrypting a terabyte of data, and why the header is everything — lose it, and the master key is gone with it (more on that at the end).

Before you type anything: the commands in steps 1–5 need a real host or VM with the device-mapper stack, and cryptsetup is not installed on the lab box — so don't expect them to run in your lab terminal (you'll get cryptsetup: command not found, and it isn't installable there). Read them here and run them on a real machine — step 6 has a loopback recipe that needs no spare disk — then come back to the lab box for the header-reading half. The lab box is for the read-only side of LUKS; the write side is real-hardware work.

luksFormat writes a fresh LUKS header onto the device and sets up key slot 0 from a passphrase you choose. It is destructive — it overwrites whatever was there — so it asks you to confirm by typing YES in capitals. On a modern system you get LUKS2 and a sensible default cipher without specifying one.

An encrypted device is opened to a mapper name under /dev/mapper/. That mapper node is the plaintext view — you make a filesystem on it and mount it exactly like a normal partition, and dm-crypt encrypts every block on the way down to /dev/sdb1.

luksDump prints the header without unlocking anything — no passphrase needed, because the header itself is not secret (only the key slots are, and those are encrypted). It is how you answer 'what cipher is this volume using?' on an incident report: the cipher name (e.g. aes), the cipher mode (xts-plain64), and the key size. The full specification a report wants is the joined form, aes-xts-plain64.

By itself an opened volume is gone after a reboot — the mapping lives in kernel memory. Two files make it persistent, and they work as a pair. /etc/crypttab says how to unlock the device into a mapper name; /etc/fstab then mounts that mapper name like any other filesystem. crypttab is read before fstab at boot precisely so the mapper node exists by the time fstab wants it.

Sealing a volume back up is the mirror image of opening it, and the order matters: unmount the filesystem first, then close the mapping. Skip the unmount and the close fails because the device is still in use. But the more important idea in this step is why an encrypted volume is so unforgiving of header damage — the same indirection that makes LUKS flexible also makes the header the one thing you cannot lose.

The lab box is a container, and that changes what of this lesson you can run here. cryptsetup is not installed on the lab image (and apt-get install cryptsetup reports "no installation candidate", so you can't add it), /dev/mapper holds only its control node, and there is no spare disk to format. That is not a gap in the room — dm-crypt is a kernel device-mapper target, and creating a mapping needs the module, the device-mapper stack, and a real block device. Steps 1–5 are how you do this on a real host or VM; run them there, on a spare disk or a loopback file, where every one of them works.

What the lab box is genuinely good for is the half of LUKS that analysis and exam tasks actually ask about: reading a header you were handed. You never need to unlock a volume — or even have cryptsetup — to answer "what cipher is this?"