/ dev / random非常に遅い？
背景情報：Red Hatサーバーでスクリプトを実行して/ dev/randomからデータを読み取り、Perlのunpack（）コマンドを使用して、後で使用するために16進数文字列に変換しようと考えていました（データベース操作のベンチマーク）。/dev/randomで「head -1」をいくつか実行しましたが、うまくいくように見えましたが、数回呼び出した後、ちょっとハングしました。数分後、最終的に小さなテキストブロックが出力され、終了します。
私は/ dev/urandomに切り替えました（本当にしたくありませんでしたし、その速度は遅く、そのような品質のランダム性は必要ありません）。それを爆撃しているのは「ヘッド」コマンドなのだろうかと思っていたので、Perlを使用して簡単なI/Oを試みましたが、それもハングしていました。最後の溝の努力として、「dd」コマンドを使用して、情報を端末からではなくファイルに直接ダンプしました。私が尋ねたのは1MBのデータだけでしたが、殺すまでに400バイトを取得するのに3分かかりました。
プロセスリストを確認しましたが、CPUとメモリは基本的に変更されていません。/dev/randomがこのように不正に動作する原因は何ですか？また、今後それを防止/修正するにはどうすればよいですか？
編集：助けてくれてありがとう！ランダムとurandomが混在しているようです。スクリプトを作成して実行しました。今日何か新しいことを学んだようです。 :)
ほとんどのLinuxシステムでは、/dev/randomは環境によって収集された実際のエントロピーから供給されます。システムが/dev/randomから大量のデータを配信していない場合、それを駆動するのに十分な環境のランダム性を生成していない可能性があります。
/dev/urandomが「遅い」または高い品質だと思う理由がわかりません。内部エントロピープールを再利用して疑似ランダム性を生成します（わずかに低品質にします）が、ブロックはしません。一般的に、高レベルまたは長期の暗号化を必要としないアプリケーションは、/dev/urandomを確実に使用できます。
しばらく待ってから、/dev/urandomからもう一度読み取ります。 /dev/randomからの内部エントロピープールの読み取りが非常に多くなり、両方のジェネレーターが破損している可能性があります。システムでエントロピーを作成すると、それらを補充できます。
/dev/randomおよび/dev/urandomの詳細については、 Wikipedia を参照してください。
この質問はかなり古いです。しかし、それでも関連性があるので、答えを出します。現在、多くのCPUにはハードウェア乱数ジェネレーター（RNG）が組み込まれています。同様に、多くのシステムには、RNGも提供するトラステッドプラットフォームモジュール（TPM）が付属しています。購入可能な他のオプションもありますが、コンピュータにすでに何かがある可能性があります。
ほとんどのLinuxディストリビューションでrng-utilsパッケージのrngdを使用して、よりランダムなデータをシードできます。たとえば、Fedora 18では、TPMおよびCPU RNG（RDRAND命令）からのシードを有効にするために必要なことは次のとおりでした。
# systemctl enable rngd
# systemctl start rngd
Rngdの有無で速度を比較できます。コマンドラインからrngd -v -fを実行することをお勧めします。これにより、検出されたエントロピーソースが表示されます。ソースをサポートするために必要なすべてのモジュールがロードされていることを確認してください。 TPMを使用するには、TPMツールを使用してアクティブにする必要があります。 update：こちらは Nice howto です。
ところで、私はインターネット上でTPM RNGがさまざまな方法で破損することがあるという懸念をいくつか読みましたが、Intel、AMD、およびVIAチップで見つかったRNGに対する具体的なものは読みませんでした。ランダム性の品質を本当に重視する場合は、複数のソースが最適です。
urandomはほとんどのユースケースに適しています（初期の起動時を除く）。最近のほとんどのプログラムは、ランダムではなくurandomを使用しています。 opensslでも それを行う 。 randomについての神話 および ランダムインターフェイスの比較 を参照してください。
最近のFedoraおよび RHEL/CentOS では、rng-toolsは jitter entropy もサポートしています。ハードウェアオプションが不足している場合や、ハードウェアよりも信頼できる場合に使用できます。
UPDATE：エントロピーを高める別のオプションは [〜＃〜] haveged [〜＃〜] （品質の問題）です。仮想マシンにはkvm/qemuがあります VirtIORNG （推奨）。
暗号的に安全な/ dev/urandomを使用します。
よく読んでください： http://www.2uo.de/myths-about-urandom/
「/ dev/randomと/ dev/urandomのどちらを使用すべきかわからない場合は、おそらく後者を使用したいでしょう。」
初期ブートで疑問がある場合は、十分なエントロピーが収集されているかどうか。代わりにシステムコールgetrandom()を使用してください。 [1]両方の長所、
- 十分なエントロピーが収集されるまで（一度だけ！）ブロックします。
- その後、再びブロックされることはありません。
/dev/randomのエントロピーをさらに増やしたい場合は、ハードウェアRNGを購入するか、 * _ entropyd daemons のいずれかを使用して生成する必要があります。
（暗号化ではなく）テストにランダム性を使用している場合、反復可能なランダム性の方が優れています。これは、既知のシードから始まる擬似ランダム性で取得できます。通常、ほとんどの言語でこれに適したライブラリ関数があります。
問題を見つけてデバッグしようとしている場合に、繰り返し使用できます。また、エントロピーを使い果たしません。/dev/urandomから疑似ランダムジェネレーターをシードし、テストログにシードを記録できます。 Perlには、使用可能な擬似乱数ジェネレータがあります。
これは私のためにそれを修正しました。 SecureRandom.getInstanceStrong（）の代わりに新しいSecureRandom（）を使用します
いくつかの詳細情報はここにあります： https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/