私が完全に混乱しない限り、それはそれをしません。
ハードウェアRNGを使用してそのエントロピーを/ dev / randomにプラグインした場合、/ dev / urandomがエントロピーを増加させるかどうかを知りたい。
言い換えると、/ dev / randomのエントロピーをXビット/秒(つまり、注入後に/ dev / randomでXビット/秒をサンプリングできるようにする)を増やすと、そのエントロピーはurandomに転送されますか?
私が完全に混乱しない限り、それはそれをしません。
ハードウェアRNGを使用してそのエントロピーを/ dev / randomにプラグインした場合、/ dev / urandomがエントロピーを増加させるかどうかを知りたい。
言い換えると、/ dev / randomのエントロピーをXビット/秒(つまり、注入後に/ dev / randomでXビット/秒をサンプリングできるようにする)を増やすと、そのエントロピーはurandomに転送されますか?
回答:
/dev/urandom
からのサンプルと言うのは本当に正確ではありません/dev/random
。代わりに、2つのプールは同じエントロピーのソースに支えられています。プールのエントロピーカウントがゼロに達すると、共有入力プールから再シードされます。そのため、何らかの方法でカーネル入力にエントロピーを与えると、どちらを読み取るかによって、どちらか/dev/random
または/dev/urandom
にそれを使用できます。
ただし、再シードを要求できる頻度も/dev/urandom
制限されています。デフォルトでは、60秒ごとに1回しか再シードできません。
プールが最初に少なくとも128ビット程度のエントロピーでシードされている限り、出力を予測するには、以前の出力を確認するだけでなく、少なくともプレイメージ耐性を含む使用されているアルゴリズムを破壊する必要があるため、実際にはそれは実際には重要ではありませんSHA-1(壊れないまま)
Linuxでは、/ dev / randomまたは/ dev / urandomに書き込まれたデータは、ブロッキングプール(/ dev / randomのランダム性のソース)とノンブロッキングプール(/ dev / urandomのランダム性のソース)の両方にコピーされます。
random_write関数を見てください。
ただし、/ dev / randomに書き込まれたデータは内部エントロピー推定器によってカウントされません(結局、一部のローカル攻撃者は/ dev / zeroまたはその他の非常に非ランダムなソースを/ dev / randomにリダイレクトしようとする可能性があります) / dev / randomをブロックして、/ dev / randomに書き込むだけでは役に立ちません。
Linuxでは、/ dev / random(または/ dev / urandom、違いなし)に書き込みますが、/ dev / urandomから常に読み取ります(シードされた後-実際には、新しいシステムコールgetrandomを使用するのが最良の方法です)。
他のユニックスでどのように機能するのかわかりません。