Estou depurando um comportamento estranho do cryptsetup:
Suponha que a senha correta esteja armazenada no arquivo pw. Eu esperava agora que --test-passphrasesempre teria sucesso (ou seja, não imprimindo nenhuma saída) se fosse passado como stdin. Mas acontece que ele falha aleatoriamente:
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
Percebi isso, pois falho constantemente várias vezes para desbloquear minha partição na inicialização (no GRUB). Primeiro, pensei que estava digitando errado, mas agora tenho a impressão de que pode ser um bug no cryptsetup. Também não consigo desbloqueá-lo consistentemente mais tarde (não no GRUB), mesmo se estiver copiando e colando a senha correta.
Observe que também difere quando passo por esta maneira (principalmente equivalente):
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
Aqui, todas as tentativas falharam, exceto uma. Enquanto a outra abordagem é bem-sucedida com mais frequência. Esse comportamento é reproduzível para mim: sempre falha com mais frequência.
# cryptsetup --version
cryptsetup 2.6.1 flags: UDEV BLKID KEYRING KERNEL_CAPI
# cryptsetup luksDump /dev/nvme0n1p2
LUKS header information
Version: 2
Epoch: 5
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 2372e472-ef96-428f-b971-f68fb0c35b63
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 13
Memory: 1048576
Threads: 4
Salt: ea b0 88 ...
f3 f9 72 ...
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 334367
Salt: f0 ac 44 ...
f3 6f d5 ...
Digest: cd a8 ...
23 2a ...
$ uname -a
Linux amd12 6.3.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 11 May 2023 16:40:42 +0000 x86_64 GNU/Linux
(OS: Arch Linux)
Eventualmente, sempre posso desbloquear, mas preciso de muitas tentativas, o que é irritante. Parece que o código de verificação ou o mecanismo para ler a entrada é inconsistente.
Eu me pergunto se é um problema conhecido (embora eu não tenha encontrado nada sobre isso)? Se não, existe uma maneira de depurar? Infelizmente, não vi nenhuma opção para obter feedback visual (acho que é considerado uma falha de segurança revelar o tamanho da senha).
Atualização: acabei de perceber que existe uma --debugopção. Embora a saída de uma execução bem-sucedida e com falha seja idêntica até o ponto em que o cálculo ocorre. Todos os cabeçalhos e somas de verificação no log de depuração são os mesmos.
Além disso, mostra o mesmo comportamento com o cryptsetup 2.4.3 em um Linux Mint Live CD.