キーが暗号化されたデータとともに保存されている場合、LUKS dm-cryptはどのように安全ですか？
私は暗号化の専門家ではありませんが、プロジェクトのよくある質問を読みました。
キーが暗号化されたデータとともに保存されている場合、LUKS dm-cryptはどのように安全ですか？私には、これはドアの鍵をロックするドアに掛けているように見えます。パスフレーズはそれを保護するのに十分ですか？
そして続き：暗号化されたパーティション/コンテナでキーを保持することが安全である場合、LUKSヘッダーバックアップも秘密データではなく通常のファイルとして扱うことができると仮定して正しいですか？
キーが暗号化されたデータとともに保存されている場合、LUKS dm-cryptはどのように安全ですか？ [...]パスフレーズはそれを保護するのに十分ですか？
はい、そうです、十分に強力なパスフレーズを選択した場合。理想的には、パスフレーズは（対称）キーと同じくらい強力である必要があります。現在の最小推奨事項は128ビットを使用することです。したがって、理想的には128ビットのパスフレーズを使用する必要があります。それが実際にどのくらいの期間であるかは、キーを生成する方法によって異なります。
- 小文字のランダムリスト、大文字（az）、および数字を使用する場合、各文字は約log2（62）= 〜5.95を示します。エントロピーのビットなので、22文字が必要になります。例：
asl3486nysdllk23bh2jl4。安全ですが、覚えるのはかなり難しいです... - ランダムな単語のリストを使用する場合は、単語リストのサイズによって異なります。たとえば、Debianの wamericanパッケージ の
american-englishファイルを使用する場合：ファイルには約99,000ワードがあるため、各ワードでlog2（99,000）= 16.6ビットのエントロピー。つまり、8ワードが必要です。例：orthogonal Seoul Pygmalion's abuse flints yachtsman's classicists outsource。まだいいとは言えませんが、おそらく上記の解決策よりも優れています...
短いパスフレーズを選択すると、はい、セキュリティが低下します（ただし、それでも許容できる場合があります）。 LUKSは キーストレッチ アルゴリズムを採用して、「弱い」キーでさえ攻撃に対してより耐性があることに注意してください。ただし、それに対する攻撃がいくつかあるため、理想的には128ビットのパスフレーズを選択する必要があります。
暗号化されたパーティション/コンテナでキーを保持することが安全である場合、LUKSヘッダーバックアップも秘密データではなく通常のファイルとして扱うことができると仮定して正しいですか？
はい、その通りです。ヘッダーのバックアップにはキーが含まれていますが、パスフレーズで保護されています。