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.
1つを除いて、すべての試みは失敗しました。他の方法が成功する可能性が高くなります。この動作は再現可能です。いつももっと頻繁に失敗します。
# 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の誤りではありません。これで、少なくとも1回のMemtest86 +実行を通過した1つのメモリブロックで再テストしました。もう再現できません。これで、両方のバージョン（< pwおよびcat pw |）は常に通過します。
修正する:RAMスロットを取り外していくつかのテストを行いました。興味深いことに、個々のスロットではうまく機能しますが、組み合わせると信頼性が低下します。機械自体は新しいものです。XMP（極端なメモリプロファイル）有効です。私が理解したところ、これは新しいハードウェアでは合理的に安全なデフォルトですが、私のコンピュータでは問題を引き起こしているようです。無効にした後、使用する準備が整いました。
たぶん、memtest86+にArgon2を含める必要があります。私のシステムでは、メモリの問題を検出することは非常に便利です。