ランダムなデータでディスクをいっぱいにしていないための救済？
暗号化の前に/ dev/urandomで大容量のHDDをいっぱいにすると、（netcat、複数のインスタンスが並行していても）非常に遅くなる可能性があるため、推奨されるプラクティスであっても、多くのユーザーがこのアドバイスをスキップすると確信しています。省略しても安全ではありません。
私の質問は次のとおりです。ユーザーがディスクに/ dev/urandomを埋めるこのステップを省略したか、部分的に実行したと仮定します。 HDDが暗号化された後、ディスクで暗号解読を実行するのを困難にするために実行できる手順はありますか？
攻撃者にとって最良のシナリオは、ユーザーがディスク全体を/ dev/zeroで埋めてから暗号化した場合だと思いますか？次に、ユーザーがファイルシステム内の任意のファイルに/ dev/zeroを書き込んで（暗号化した後）ディスク全体を満たし、そのファイルを削除して「使用済み」スペースを回復した場合に役立ちますか？これにより、デバイス上の余分なnullバイトが削除され、すべてが暗号化されたデータで置き換えられませんか？
それで、より現実的なケースでは、暗号化された後にディスクをデータで満たすのに役立ちますか？そうでない場合、なぜそうではないのですか？暗号化された後、ディスクが実際に最大容量までいっぱいになったと想像してください。暗号化の前にランダムデータで以前にいっぱいになった場合、どのような値になりますかとにかく/ dev/urandomデータはすべて上書きされているので、その段階でその操作はどのような値を保持していますか？
必要に応じて、システムがLUKSを備えたx86-64 GNU/Linux、256ビットAES、機械式HDDであると想定します（SSDでこの変更はありますか？興味深いので、その理由を含めてください）。
攻撃シナリオ：HDDが盗まれ、攻撃者によってコンピューターから取り除かれ、悪意のあるメイドやコールドブート攻撃などの攻撃が防止されます。
HDDが暗号化された後、ディスクで暗号解読を実行するのを困難にするために実行できる手順はありますか？
ディスクはすでに暗号化されているので、残りのファイルシステム領域を（ランダム）データで埋めることをお勧めします。/dev/urandomをファイル（後で削除できます）にパイプします。そうすることで、基盤となる（ブロック）デバイスが暗号化されたデータ（「ノイズ」）でいっぱいになります。
それで、より現実的なケースでは、暗号化された後にディスクをデータで満たすのに役立ちますか？
はい、それは役立ちます-上記を参照してください。
暗号化された後、ディスクが実際に最大容量までいっぱいになったと想像してください。暗号化の前にランダムデータで以前にいっぱいになった場合、どのような値になりますか
まあ、最初の暗号化の前にそれを行うと、後でそれを忘れることからあなたを保護します。つまり午前中に完全なディスク暗号化を設定し、「今晩後半にディスクをいっぱいにします」が、その間にディスクが盗まれた.
注：完全なディスク暗号化が完了した後でも、ディスクのコントローラーはディスクの一部をゼロにすることができない場合があります。 そのトピックの詳細については、Data_remanence を参照してください。
完全にランダムに上書きされていない暗号化されたディスクから攻撃者が抽出できる唯一の情報は、ディスク上の暗号化された情報の量の上限です。
別の言い方をすれば、優れたディスク暗号化ソリューションは、攻撃者がセキュリティプロパティの暗号化されたパーティションの境界を決定できないことに依存するべきではありません。
暗号化後にディスクをデータで満たすと、期待した結果が得られるはずです（暗号化されたパーティションが動的に拡張してディスク全体を満たす場合）：ディスク上のすべてのデータがランダムに表示されるはずです（パーティションテーブルなどはマイナスに依存する）ソリューション）。
暗号化の前に/ dev/urandomで大容量のHDDをいっぱいにすると、（netcat、複数のインスタンスが並行していても）非常に遅くなる可能性があるため、推奨されるプラクティスであっても、多くのユーザーがこのアドバイスをスキップすると確信しています。省略しても安全ではありません。
新しいLinuxカーネルでは、/dev/urandomデバイスは、より遅いSHA1ミキシング機能ではなく、ランダム性のためにChaCha20を使用して、非常に高速にすることができます。新しいカーネルがない場合、単純な解決策は、OpenSSLまたはdm-cryptを使用してランダム性を作成することです。
OpenSSLは最も単純で、必要なコマンドは1つだけです。
openssl aes-128-ctr -nosalt -in /dev/zero -out /dev/sdX -k $(head -c16 /dev/urandom | base64)
Dm-cryptの使用はより複雑ですが、多くの場合、より高速なカーネルアクセラレーション暗号を使用できます。
cryptsetup open -M plain -c aes-cbc-plain -s 128 -d /dev/urandom /dev/sdX wipeme
cat /dev/zero > /dev/mapper/wipeme
cryptsetup close wipeme
私の質問は次のとおりです。ユーザーがディスクに/ dev/urandomを埋めるこのステップを省略したか、部分的に実行したと仮定します。 HDDが暗号化された後、ディスクで暗号解読を実行するのを困難にするために実行できる手順はありますか？
まず第一に、問題は、それが暗号解読を容易にすることではありません。 AESはそれほど脆弱ではないため、単なるギガバイトの既知のプレーンテキストで鍵を復元できます。最強のPRNGのいくつかは、ランダムキーでnullストリームを暗号化することによってランダムデータを生成します。問題はむしろファイルシステムレベルのメタデータの漏洩（どのブロックがフリーでどれがフリーではないかを知る）であり、ファイルシステムの全体的なレイアウトが失われます。これにより、使用されている容量だけでなく、ファイルサイズ、位置、ファイルに対して実行された以前のアクションなど、より多くの情報が漏洩する可能性があります。暗号化されたファイルのメタデータ（サイズなど）のみに基づいて逮捕や有罪判決が下される場合があります。
攻撃者にとって最良のシナリオは、ユーザーがディスク全体を/ dev/zeroで埋めてから暗号化した場合だと思いますか？次に、ユーザーがファイルシステム内の任意のファイルに/ dev/zeroを書き込んで（暗号化した後）ディスク全体を満たし、そのファイルを削除して「使用済み」スペースを回復した場合に役立ちますか？これにより、デバイス上の余分なnullバイトが削除され、すべてが暗号化されたデータで置き換えられませんか？
はい、そうするのが良いでしょう。ファイルシステムがいっぱいになってもワイプされない領域が残っているため、完全ではありません。たとえば、非rootユーザーは、デフォルトではext4ファイルシステムの最後の5％のスペースを上書きできません。また、ファイルシステムの作成時に初期化されず、nullバイトのままにされる可能性がある特定のメタデータフィールドをユーザーが上書きすることはできません。初期化されていない可能性のあるフィールドや機密情報が漏洩する可能性があるフィールドを理解するには、特定のファイルシステムで使用されているディスク上のフォーマットおよびフォーマットテクニックを調べる必要があります。これは非常に複雑なタスクであることが多いため、ランダム化されたブロックデバイスから始めるのが一般的に簡単です。
一部のデータを暗号化しないままにしておくことで問題を理解するのに非常に役立つ投稿は here です。具体的には、SSD上のTRIMに関する投稿ですが、TRIMは解放されたブロックをゼロにし、解放されているブロックと解放されていないブロックに関する情報をリークするため、効果は同じです。これは、これがSSDにどのように適用されるかについてのあなたの質問に答える場合もあります。