これは多少「私も」の答えですが、トム・ヘイルの推奨を強化します。それは正にLinuxに適用されます。
/dev/urandomを使用/dev/randomは使用しないでください
Linux Kernel CryptoメーリングリストのTheodore Ts'oによると、/dev/randomは10年間非推奨になっています。 From Re：[RFC PATCH v12 3/4] Linux Random Number Generator ：
/ dev/randomを実際に使用する人はいません。これは本質的に非推奨のインターフェースです。 10年以上にわたって推奨されてきた主要なインターフェースは/ dev/urandomで、現在はgetrandom（2）です。
私たちは定期的に/dev/randomをテストしており、頻繁に失敗します。このテストでは、次の3つのステップを実行します。（1）ノンブロッキングモードで10Kバイトを要求して、/dev/randomをドレインします。 （2）ブロックモードで16バイトを要求します（3）ブロックを圧縮して、ランダムかどうかを確認します（貧困層のテスト）。テストの完了には数分かかります。
問題は、Debainシステム（i686、x86_64、ARM、およびMIPS）では非常に悪いため、テストマシン用のrng-toolsパッケージをインストールするようGCC Compile Farmに依頼しました。から gcc67とgcc68にrng-toolsをインストール ：
Rng-toolsをgcc67とgcc68にインストールするようにリクエストします。それらはDebianシステムであり、/ dev/randomは、デバイスを利用するテストライブラリを拷問するときに、rng-toolsなしではエントロピーの枯渇を被ります。
BSDとOS Xは問題ありません。問題は間違いなくLinuxです。
Linuxはジェネレーターの失敗をログに記録しないことも言及する価値があるかもしれません。システムログがいっぱいになるエントリは必要ありませんでした。これまでのところ、ほとんどの障害はサイレントであり、ほとんどのユーザーによって検出されません。
カーネルは少なくとも1つの失敗メッセージを出力するため、状況はまもなく変化するはずです。カーネル暗号化メーリングリストの [[PATCH] random：コンパイラの警告を抑制し、競合を修正する から：
具体的には、
depends on DEBUG_KERNELを追加しました。これは、これらの有用な警告が他のカーネル開発者を突くだけであることを意味します。これはおそらく私たちが望むものです。さまざまな関連する開発者が特定のサブシステムからの警告を見つけた場合、彼らはそれを修正する意欲が高まります。通常のユーザーはDEBUG_KERNELを使用していないため、ディストリビューションカーネルの通常のユーザーには警告やスパムは表示されません。セキュリティエンジニアリングの観点からすべてのメッセージを抑制することは悪い考えだと思います。
多くの人々はデバッグカーネルを実行しません。問題を知りたい、または知る必要があるユーザーのほとんどは、問題が発生していることに気づかないでしょう。 systemdの問題を知った理由は、dmesgの問題が原因であると考えてください。
すべての構成のすべてのメッセージを抑制すると、必要以上に広いネットがキャストされます。潜在的に検出および修正される可能性のある構成は、気付かれない可能性があります。問題が明らかにならない場合は、修正されません。
一部の組織では、カーネルがポリシーを決定しているように感じます。事実上修正不可能なハードウェアを持っている人にとって、組織はリスクの逆境に基づいて何をすべきかを決定する必要があります。彼らはリスクに耐えることを決定するかもしれませんし、ハードウェアをリフレッシュすることを決定するかもしれません。ただし、問題に関する情報がないと、実用的なアイテムがあることに気付かない可能性もあります。
最終的にスレッドで到達した妥協点は、呼び出しモジュールごとに少なくとも1つのdmesgでした。
伝統的に、/dev/urandomと/dev/randomの唯一の違いは、カーネルがシステムにエントロピーがないと考えたときに何が起こるかです。/dev/randomがクローズに失敗し、/dev/urandomがオープンに失敗します。両方のドライバーは、add_disk_randomness()、add_interrupt_randomness()、およびadd_input_randomness()からエントロピーを調達していました。詳細については、/drivers/char/random.cを参照してください。
編集して追加：Linux 4.8以降、/dev/urandomはCSPRNGを使用するように修正されました。
では、いつフェールクローズする必要がありますか？あらゆる種類の暗号化の使用、特にDRBGのシード。 RSAキーを生成するときに/dev/urandomを使用し、十分なエントロピーがない場合の結果を説明する非常に優れた論文があります。 マイニングあなたのpsとqs を読んでください。