LUKS2 vs LUKS1: differences, how to check, and how to convert

Short answer: LUKS2 is the current on-disk format for Linux disk encryption and the default in cryptsetup since 2.1. Compared with LUKS1 it adds a redundant, checksummed JSON metadata header, the memory-hard Argon2id key derivation instead of PBKDF2, 32 keyslots instead of 8, tokens for TPM2 and FIDO2 unlocking, and optional authenticated encryption. Use LUKS2 unless an old GRUB must decrypt `/boot` by itself.

Both formats encrypt the data the same way, typically AES-XTS. What differs is the header: how keys are stored, how hard passphrases are to brute-force, and what tooling can read it. This guide covers the differences, how to check which one you have, and how to convert with `cryptsetup convert` without losing the disk. If you are encrypting a fresh server for a self-hosting stack on a small VPS, LUKS2 is the format to pick.

LUKS2 vs LUKS1 at a glance

Header format and keyslots

A LUKS1 header is a fixed binary structure followed by eight keyslot areas. If the first sectors of the device are overwritten, for example by a mistaken `mkfs` or a partitioning tool, every keyslot is gone and the data is lost unless you have a header backup.

LUKS2 stores a binary header and a JSON metadata area, and keeps a second copy of both. Each copy carries a checksum, so `cryptsetup` can detect corruption and fall back to the other copy. The JSON area describes keyslots, segments, digests and tokens, which is what makes new features possible without changing the format again. Redundancy still does not replace a header backup: a full overwrite of the first megabytes destroys both copies.

Argon2id vs PBKDF2

The passphrase is never used directly as a key. A key derivation function stretches it so each guess is expensive. LUKS1 can only use PBKDF2, which is cheap to run on GPUs and ASICs, so an attacker with a copied header can test passphrases in parallel at high speed.

LUKS2 defaults to Argon2id, which requires a configurable amount of memory per guess (up to 1 GiB by default, capped by available RAM at format time) and is far more expensive to parallelize. A strong passphrase is still the main defense, but Argon2id raises the cost of every guess considerably.

On small servers, keep memory cost in mind. A keyslot created on a machine with lots of RAM may need more memory to unlock than a 1 GB VPS, such as the NoctisNode Wisp plan, can spare inside the initramfs. Set it explicitly with `--pbkdf-memory` (in KiB) when formatting or adding keys on a large machine for a small one.

# Inspect PBKDF parameters of each keyslot
cryptsetup luksDump /dev/vda3 | grep -A6 '^  [0-9]*: luks2'

# Re-derive keyslot 0 with Argon2id and 512 MiB memory cost
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 \
  --pbkdf argon2id --pbkdf-memory 524288

Tokens, integrity and GRUB caveats

Tokens are JSON objects in the LUKS2 header that tell tools how to obtain a key automatically. `systemd-cryptenroll` uses them to bind a keyslot to a TPM2 chip, a FIDO2 security key or a PKCS#11 smartcard, and Clevis uses them for network-bound unlocking with a Tang server. None of this exists on LUKS1.

Integrity mode (`cryptsetup luksFormat --integrity hmac-sha256`) combines encryption with dm-integrity so tampered sectors produce read errors instead of silently altered data. It costs disk space and write speed, requires a full wipe at format time and is still marked experimental. Most servers do not use it.

GRUB is the main reason people still meet LUKS1. Upstream GRUB 2.06 and later can open LUKS2, but only keyslots using PBKDF2, because Argon2 support is not part of upstream GRUB. If GRUB itself must decrypt an encrypted `/boot`, use LUKS1 or a LUKS2 keyslot with `--pbkdf pbkdf2`. The Debian and Ubuntu installers keep `/boot` unencrypted, so the kernel and initramfs do the unlocking and Argon2id works, including for remote unlock over SSH.

How to check whether a volume is LUKS1 or LUKS2

Any of these works on a running system, as root. The `Version:` line of `cryptsetup luksDump` is the authoritative answer; the dump also shows keyslots, PBKDF type and tokens.

# Find encrypted partitions (FSVER column shows 1 or 2)
lsblk -f

# Authoritative: header version
cryptsetup luksDump /dev/vda3 | grep -E '^Version'
# Version:        2

# Exit code 0 only if the device is LUKS2
cryptsetup isLuks --type luks2 /dev/vda3 && echo LUKS2

Converting with cryptsetup convert

`cryptsetup convert` rewrites the header in place; the encrypted data is not touched. The device must be closed, so for a root filesystem you run it from a rescue or live system. A failure or power loss mid-conversion can leave the header unusable, which is why the backup step is not optional.

1. 01.Boot a rescue or live system and make sure the LUKS device is not open (`cryptsetup close` if needed).
2. 02.Back up the header with `cryptsetup luksHeaderBackup` and copy the file off the server. Anyone with this file and an old passphrase can unlock the disk, so store it encrypted.
3. 03.Convert LUKS1 to LUKS2 with `cryptsetup convert --type luks2`. Existing keyslots stay PBKDF2.
4. 04.Upgrade each keyslot to Argon2id with `cryptsetup luksConvertKey --pbkdf argon2id`, unless GRUB must read it.
5. 05.Test that the device opens, then rebuild the initramfs with `update-initramfs -u` and reboot.
6. 06.To go back from LUKS2 to LUKS1, first convert every keyslot to PBKDF2 and remove tokens and LUKS2-only features; otherwise `cryptsetup convert --type luks1` refuses.

# From a rescue system, device closed
cryptsetup luksHeaderBackup /dev/vda3 --header-backup-file /root/vda3-luks-header.img

cryptsetup convert --type luks2 /dev/vda3
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 --pbkdf argon2id

cryptsetup open /dev/vda3 cryptroot && cryptsetup close cryptroot

# Emergency restore (overwrites the current header!)
# cryptsetup luksHeaderRestore /dev/vda3 --header-backup-file /root/vda3-luks-header.img

Note · After a header restore, the passphrases valid at backup time work again, including ones you removed later. Delete old header backups when you rotate passphrases. Keep the current backup somewhere separate, for example in the repository described in the restic backups guide.

FAQ