ランダムシードが適時にエントロピープールに伝播しない
Linuxカーネルのランダム性ドライバーは、環境からエントロピーを収集します。起動中のエントロピーはほとんどないため、ランダムシードは_/var/lib/misc/random-seed_または同様の場所に保持されることがよくあります。システムがシャットダウンすると、新しい512バイトのランダムシードがこのファイルに書き込まれます。システムが起動すると、このファイルは_/dev/urandom_に書き込まれ、エントロピープールに追加されます。ポイントは、再起動後もエントロピープールの状態を維持できるようにすることです。問題があります：
ノンブロッキングプールに書き込まれたデータは最初に入力プールに入れられ、「壊滅的な再シード」のために十分なエントロピーが収集された後でのみ使用可能になります。つまり、ランダムシードのエントロピーが実際にCSPRNGに影響を与えるまでに数分かかる場合があります。
同じ理由で、システムが起動して数分以内にシャットダウンした場合、書き込まれる新しいシードには以前のシードからのエントロピーがなく、予測がはるかに簡単になります。これは、システムが永続的なエントロピーシードをかなり頻繁に効果的にリセットすることを意味するため、稼働時間が非常に短いシステムではおそらく問題になります。
私の分析は正しいですか？これらの問題の実際の影響は何ですか？たとえば、一般的に使用されているシステム（特に組み込みシステム）のうち、再起動から数分以内に予測不可能なランダム性が必要なシステムや、稼働時間が非常に短いシステムはありますか？
カーネルのランダム性ドライバーでは、ブロッキングプールまたは非ブロッキングプールへの writing が random_write() 操作をトリガーし、その内部で write_pool() 入力プールを引数として指定します。入力プールは、 Push_to_pool() ワークキュー関数を介してブロッキングプールを再シードするために定期的に使用されます。 _extract_crng() が呼び出されて非ブロッキングプールからデータが抽出されると、非ブロッキングプールは5分ごとに入力プールから再シードします（少なくとも128ビットのエントロピーが最後の再シード以降の入力プール）。この情報の流れは、再起動後に保存されたランダムシードは、（64ビット）壊滅的な再シード後のブロッキングプールのコンテンツにのみ影響し、ノンブロッキングCRNGは5分ごとに影響することを意味します。
私が質問しなければならないいくつかの仮定があります：
A.「ブート中にエントロピーがほとんどないため」。
B.「ポイントは、エントロピープールの状態を再起動後も維持できるようにすることです」
対処A：たまたま使用する特定のシステム構成でエントロピーの問題が発生する可能性がありますが、これは一般的な問題ではありません。ただし、「Mining Your Ps and Qs：Detection of Widespread Weak Keys in Network Devices」とN. Heningerはそのような状態について説明していますヘッドレスシステム。この状態が発生するには、複数のエントロピーソースが存在しないか、パフォーマンスが低下している必要があります。まず、ヘッドレスシステムである必要があるため、add_input_randomness（）からのエントロピーはありません。次に、非常に限定されたコントローラーアクティビティである必要があり、これにはネットワークカードが含まれるため、add_interrupt_randomness（）を駆動する割り込みはほとんどありません。 3番目に、ブロックデバイス（ハードディスクなど）があってはならないため、add_disk_randomness（）はエントロピーを生成しません。たとえば、最新のSATA3 SSDは、起動時にadd_disk_randomness（）を使用してそれ自体で約200ビットのエントロピーを生成します。
対処B：エントロピープールの状態を保存することは、深刻な問題に対する不完全な解決策です。起動時間のエントロピーが低い場合は、それが注目すべき重要な問題です。また、頻繁に再起動すると、このような問題は壊滅的になります。保存されたエントロピー設計を改善しても、エントロピーの欠如という根本的な問題は解決されません。