/dev/urandomプログラムのランダムデータを生成するために使用しています。とは異なり、十分なバイト数が生成されない場合は SHA を使用しない/dev/randomため、 が空になる可能性があることを知りました。「カーネルエントロピープール」を使用します。どうやら、キーボードのタイミング、マウスの動き、および IDE のタイミングに依存しているようです。/dev/urandom/dev/random
しかし、これは実際にどのように機能するのでしょうか?
また、エントロピー プールを「フィード」して /dev/random 出力を予測可能にすることはできないでしょうか?
あなたが言っていることは的を射ています。はい、理論的にはエントロピーを にフィードすることは可能/dev/randomですが、それが重要であるためには、多くのカーネル「ノイズ」ソースを制御する必要があります。random.cのソースを見て、どこ/dev/randomからノイズを拾うかを確認できます。基本的に、かなりの数のノイズ ソースを制御すると、他のノイズ ソースがエントロピー プールに寄与しているものを推測できます。
はからシードされ/dev/urandomたハッシュ チェーン/dev/randomであるため、シードがわかっていれば、次の数値を実際に予測できます。エントロピー プールを十分に制御できる場合は、 の出力から/dev/urandomこのシードを推測できる可能性があります。これにより、 から次のすべての数値を予測できるようになりますが、使い果たされ/dev/urandomたままにしておく場合に限り、再シードされます。/dev/random/dev/urandom
そうは言っても、制御された環境でさえ、実際にそれを行う人を見たことがありません. もちろん、これは保証ではありませんが、心配する必要はありません。
したがって、マウスを動かしたり、キーボードを叩いたりするなど、愚かなことをユーザーに要求するの/dev/urandomではなく、エントロピーを待っている間にプログラムがブロックされないことを使用して保証したいと思います。/dev/random
LWN のエントロピーとランダム性について読むべきだと思います。うまくいけば、心配が和らぐでしょう :-)。
それでも心配な場合は、HRNGを取得してください。
編集 ここにエントロピーに関する小さなメモがあります：
エントロピーの概念は一般的に理解しにくいと思います。ウィキペディアに詳しい記事があります。しかし基本的に、この場合、エントロピーはランダム性と読むことができます。
つまり、色付きのボールの大きな袋があり、この袋のエントロピーが高いほど、袋から引き出される次の色を予測するのが難しくなります。
このコンテキストでは、エントロピー プールは単なるランダム バイトの集まりであり、前のものや他のものから派生させることはできません。つまり、エントロピーが高いということです。
jbrの回答の深さに感謝します。
現在 ipsec pki コマンドまたは空のエントロピー プールをブロックしている同様のものを見つめている人のために、実用的な更新を追加します。
rng-tools を別のウィンドウにインストールしたところ、pki コマンドが完了しました。
apt-get install rng-tools