LUKS2 vs LUKS1: diferenças, como verificar e como converter

Resposta curta: o LUKS2 é o formato em disco atual da criptografia de disco no Linux e o padrão do cryptsetup desde a versão 2.1. Em comparação com o LUKS1, ele acrescenta um header de metadados JSON redundante e com checksum, a derivação de chave Argon2id (memory-hard) no lugar do PBKDF2, 32 keyslots em vez de 8, tokens para desbloqueio via TPM2 e FIDO2 e criptografia autenticada opcional. Use LUKS2, a menos que um GRUB antigo precise descriptografar o `/boot` sozinho.

Os dois formatos criptografam os dados da mesma forma, normalmente com AES-XTS. O que muda é o header: como as chaves são armazenadas, quão difícil é quebrar as passphrases por força bruta e quais ferramentas conseguem lê-lo. Este guia cobre as diferenças, como verificar qual você tem e como converter com `cryptsetup convert` sem perder o disco. Se você está criptografando um servidor novo para uma stack de self-hosting num VPS pequeno, o LUKS2 é o formato a escolher.

LUKS2 vs LUKS1 num relance

Formato do header e keyslots

Um header LUKS1 é uma estrutura binária fixa seguida de oito áreas de keyslot. Se os primeiros setores do dispositivo forem sobrescritos, por exemplo por um `mkfs` por engano ou por uma ferramenta de particionamento, todos os keyslots se perdem e os dados também, a menos que você tenha um backup do header.

O LUKS2 armazena um header binário e uma área de metadados JSON, e mantém uma segunda cópia de ambos. Cada cópia tem um checksum, então o `cryptsetup` consegue detectar corrupção e recorrer à outra cópia. A área JSON descreve keyslots, segmentos, digests e tokens, e é isso que permite novos recursos sem mudar o formato de novo. Ainda assim, a redundância não substitui um backup do header: sobrescrever por completo os primeiros megabytes destrói as duas cópias.

Argon2id vs PBKDF2

A passphrase nunca é usada diretamente como chave. Uma função de derivação de chave a "estica" para que cada tentativa seja cara. O LUKS1 só pode usar PBKDF2, que é barato de rodar em GPUs e ASICs, então um atacante com uma cópia do header consegue testar passphrases em paralelo e em alta velocidade.

O LUKS2 usa Argon2id por padrão, que exige uma quantidade configurável de memória por tentativa (até 1 GiB por padrão, limitada pela RAM disponível no momento da formatação) e é muito mais caro de paralelizar. Uma passphrase forte continua sendo a principal defesa, mas o Argon2id aumenta consideravelmente o custo de cada tentativa.

Em servidores pequenos, tenha o custo de memória em mente. Um keyslot criado numa máquina com muita RAM pode precisar de mais memória para desbloquear do que um VPS de 1 GB, como o plano Wisp da NoctisNode, consegue disponibilizar dentro do initramfs. Defina-o explicitamente com `--pbkdf-memory` (em KiB) ao formatar ou adicionar chaves numa máquina grande para uso numa pequena.

# 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, integridade e ressalvas do GRUB

Tokens são objetos JSON no header LUKS2 que dizem às ferramentas como obter uma chave automaticamente. O `systemd-cryptenroll` os usa para vincular um keyslot a um chip TPM2, a uma chave de segurança FIDO2 ou a um smartcard PKCS#11, e o Clevis os usa para desbloqueio vinculado à rede com um servidor Tang. Nada disso existe no LUKS1.

O modo de integridade (`cryptsetup luksFormat --integrity hmac-sha256`) combina criptografia com dm-integrity para que setores adulterados gerem erros de leitura em vez de dados alterados silenciosamente. Ele custa espaço em disco e velocidade de escrita, exige uma limpeza completa na formatação e ainda é marcado como experimental. A maioria dos servidores não o usa.

O GRUB é o principal motivo pelo qual as pessoas ainda encontram LUKS1. O GRUB upstream 2.06 e posteriores conseguem abrir LUKS2, mas só keyslots que usam PBKDF2, porque o suporte a Argon2 não faz parte do GRUB upstream. Se o próprio GRUB precisa descriptografar um `/boot` criptografado, use LUKS1 ou um keyslot LUKS2 com `--pbkdf pbkdf2`. Os instaladores do Debian e do Ubuntu mantêm o `/boot` sem criptografia, então são o kernel e o initramfs que fazem o desbloqueio e o Argon2id funciona, inclusive para o desbloqueio remoto via SSH.

Como verificar se um volume é LUKS1 ou LUKS2

Qualquer uma destas opções funciona num sistema em execução, como root. A linha `Version:` do `cryptsetup luksDump` é a resposta definitiva; o dump também mostra os keyslots, o tipo de PBKDF e os 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

Convertendo com cryptsetup convert

O `cryptsetup convert` reescreve o header no lugar; os dados criptografados não são tocados. O dispositivo precisa estar fechado, então para um sistema de arquivos raiz você o executa a partir de um sistema de resgate ou live. Uma falha ou queda de energia no meio da conversão pode deixar o header inutilizável, e é por isso que a etapa de backup não é opcional.

1. 01.Inicie um sistema de resgate ou live e confirme que o dispositivo LUKS não está aberto (`cryptsetup close`, se necessário).
2. 02.Faça backup do header com `cryptsetup luksHeaderBackup` e copie o arquivo para fora do servidor. Qualquer pessoa com esse arquivo e uma passphrase antiga consegue desbloquear o disco, então guarde-o criptografado.
3. 03.Converta LUKS1 para LUKS2 com `cryptsetup convert --type luks2`. Os keyslots existentes continuam em PBKDF2.
4. 04.Atualize cada keyslot para Argon2id com `cryptsetup luksConvertKey --pbkdf argon2id`, a menos que o GRUB precise lê-lo.
5. 05.Teste se o dispositivo abre, depois recompile o initramfs com `update-initramfs -u` e reinicie.
6. 06.Para voltar de LUKS2 para LUKS1, primeiro converta todos os keyslots para PBKDF2 e remova os tokens e os recursos exclusivos do LUKS2; caso contrário, `cryptsetup convert --type luks1` se recusa.

# 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 · Depois de restaurar um header, as passphrases válidas no momento do backup voltam a funcionar, inclusive as que você removeu depois. Apague os backups antigos do header ao trocar as passphrases. Guarde o backup atual num lugar separado, por exemplo no repositório descrito no guia de backups com restic.

Perguntas frequentes