cryptsetup의 이상한 동작을 디버깅하고 있습니다.
올바른 비밀번호가 파일에 저장되어 있다고 가정합니다 pw. 이제 --test-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
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.
부팅 시 GRUB에서 파티션을 여러 번 잠금 해제할 수 없었기 때문에 이 문제를 발견했습니다. 처음에는 오타가 있는 줄 알았는데 지금은 cryptsetup의 버그일지도 모른다고 생각합니다. 올바른 비밀번호를 복사하여 붙여넣어도 나중에 일관되게 잠금을 해제할 수 없습니다(GRUB에서는 아님).
다음과 같은 (대부분 동등한) 방식으로 전달할 때도 다릅니다.
# 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.
하나를 제외하고 모든 시도가 실패했습니다. 다른 방법이 성공할 가능성이 더 높습니다. 이 동작은 재현 가능합니다. 항상 더 자주 실패합니다.
# 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)
결국 언제든지 잠금을 해제할 수 있었지만 여러 번 시도해야 했기 때문에 짜증이 났습니다. 보안 문자나 입력 내용을 읽는 메커니즘이 불안정한 것 같습니다.
이것이 알려진 문제인지 궁금합니다(아직 이에 대해 아무것도 찾지 못했지만). 그렇지 않다면 디버깅할 수 있는 방법이 있나요? 안타깝게도 시각적 피드백을 얻을 수 있는 옵션은 없습니다. 비밀번호 길이를 공개하는 것은 보안 결함으로 간주됩니다.
고쳐 쓰다:방금 옵션이 있다는 것을 깨달았습니다 --debug. 성공한 실행과 실패한 실행의 출력은 계산이 발생할 때까지 동일합니다. 디버그 로그의 모든 헤더와 체크섬은 동일합니다.
또한 Linux Mint Live CD의 cryptsetup 2.4.3과 동일한 동작을 보여줍니다.
답변1
@frostschutz가 맞습니다. Memtest86+를 실행할 때 내 컴퓨터의 메모리에 오류가 표시되는 것으로 나타났습니다.
가장 가능성 있는 설명은 RAM의 어느 부분이 사용되고 있는지에 따라 계산이 성공하거나 실패한다는 것입니다. Argon2(현재 키 파생의 기본값)는 계산 중에 많은 메모리를 사용합니다.
그러나 이것은 cryptsetup의 잘못이 아닙니다. 이제 최소한 한 번의 Memtest86+ 실행을 통과한 단 하나의 메모리 블록으로 다시 테스트했습니다. 더 이상 재현할 수 없습니다. 이제 두 버전( < pw및 cat pw |) 모두 항상 통과합니다.
고쳐 쓰다:RAM 슬롯을 제거하여 몇 가지 테스트를 더 수행했습니다. 흥미롭게도 개별 슬롯에서는 잘 작동하지만 조합하면 신뢰성이 떨어집니다. 기계 자체는 새것인데 보니까XMP(익스트림 메모리 프로필)활성화되었습니다. 내가 이해한 바에 따르면 이는 새 하드웨어에서는 합리적으로 안전한 기본값이지만 내 컴퓨터에서는 문제를 일으키는 것 같았습니다. 비활성화한 후 이제 사용할 준비가 되었습니다.
어쩌면 memtest86+에 Argon2를 포함해야 할 수도 있습니다. 내 시스템에서는 메모리 문제를 감지하는 것이 매우 유용합니다.