--key-file引数が指定されていない限り、luksOpenはkeyfileで復号化しません
最初にインタラクティブにパスフレーズを設定した暗号化されたボリュームがあります。これはパーティションを解読するのにうまく機能します。次の両方の方法で、キーファイルを使用してさらにキーを追加しました。
cryptsetup --keyfile=passphrase luksAddKey /dev/sdax
cryptsetup --luksAddKey /dev/sdax passphrase
ここで、パスフレーズはキーを含むファイルで、/ dev/sdaxは暗号化されたボリュームです。
次に、パスフレーズが有効かどうかを確認しました。
cat passphrase | cryptsetup --test-passphrase luksOpen /dev/sdax
dd if=passphrase bs=1 count=256 | cryptsetup --test-passphrase luksOpen /dev/sdax
しかし、どちらも失敗しました。「このパスフレーズで使用できるキーはありません。」 --key-fileオプションを使用する次のコマンドが機能しました。
cryptsetup --test-passphrase --key-file passphrase luksOpen /dev/sdax
この時点で、パスフレーズのコンテンツをパイプ処理する方法が、唯一の有効なパスフレーズ（対話的に設定）で機能するかどうかを確認しようとしました。
echo "manually written working passphrase" > interactive_pass
cat interactive_pass | cryptsetup luksAddKey /dev/sdax
今回はうまくいきました。 2つの方法と2つのキーファイルの違いは何ですか？ crypttabでスクリプトを使用する場合に唯一可能な方法と思われるため、キーファイルから追加されたパスフレーズでも機能するように、ファイルコンテンツをパイプする最初の方法が必要になります。出来ますか？
これについては、NOTES ON PASSPHRASE PROCESSING FOR LUKSのcryptsetupのマニュアルページで詳しく説明しています。改行を含めるかどうか、サイズ制限の違いなどの違いがあります（たとえば、インタラクティブパスフレーズの場合は512バイト、cryptsetup --helpを確認してください）、...
この面倒な作業を避けたい場合は、インタラクティブなcryptsetupプロンプトに端末で入力するときにも機能するキーファイルを作成するのが最善です。つまり、キーファイルはプレーンテキスト文字列である必要があり、末尾に改行文字を含めないでください。 （echo -nまたはprintf "%s"を使用してください。）
たとえば、pwgenを使用して64文字のパスワードkeyfile.txtを生成し、緊急時に手動で入力することもできます。
$ echo -n $(pwgen 64 1) | tee keyfile.txt
Aish6shaejongi9yug3quij7aijop7SieTh7ierahngaem8iov5isho5dae0pisu
このようなキーファイルでは、cryptsetupに渡す方法に関係なく、解釈に違いはありません。例外は、入力時に誤ったキーボードレイアウトを使用することです。キーボードレイアウトの問題が予想される場合は、 パスフレーズを2回追加できます なので、LUKSはどちらかを受け入れます。
これは、/dev/urandomキーファイルを使用する場合に特に重要です...間違った方法で使用すると、処理が早い段階で停止し（ランダムな改行文字が表示されます）、パスワードが思ったよりもはるかに短い場合があります。 。
-hオプションを使用する必要があります。パスフレーズは、キーファイルとして使用する前に最初にハッシュされます。これが、数文字から256ビットまたは512ビットに変換する方法です。したがって、luksFormatに使用したオプションと、それをロック解除する方法に応じて、たとえば、次のように指定する必要があります。 -h plainまたはその他のパラメーター。
標準入力でパスフレーズを渡すと、cryptsetupは入力の1行を読み取り、この行の最後の改行と後続の行を破棄します。
--key-fileを使用してファイルからパスフレーズを渡すと、ファイルの完全な内容が使用されます。ファイルに改行が含まれている場合、パスフレーズは標準入力で渡されるものと同一にすることはできません。