/ dev / randomと/ dev / urandomを使用する場合

/dev/randomまたはを使用する必要がありますか/dev/urandom？

どちらの状況で他の状況よりも好むでしょうか？

TL; DR

/dev/urandom最も実用的な目的に使用します。

長い答えは、実行しているUnixのフレーバーによって異なります。

Linux

歴史的に、/dev/randomそして/dev/urandom両方同時に導入されました。

@DavidSchwartz がコメントで指摘したように、/dev/urandomほとんどの場合に使用することが推奨されます。彼と他の人たちは、さらに読むことをお勧めする記事について/dev/urandomの素晴らしい神話へのリンクも提供しました。

要約すれば：

• manページは、誤解を招きます
• 両方が同じ CSPRNGによって供給され、ランダム性を生成します（図2および3）
• /dev/random エントロピーがなくなるとブロックする
• エントロピーの量は控えめに推定されますが、カウントされません
• /dev/urandomブロックすることはなく、読み取りは/dev/randomプロセスの実行を停止できます。
• まれに、ブート直後に、CSPRNGに適切なシードを/dev/urandom行うのに十分なエントロピーがなく、高品質のランダム性が得られない場合があります。
• CSPRNGが最初に適切にシードされていれば、エントロピーが少なくても問題ありません
• CSPRNGは常に再シードされています
• Linux 4.8以降で/dev/urandomは、（によって使用される/dev/random）エントロピープールを使い果たしませんが、アップストリームからのCSPRNG出力を使用します。
• を使用し/dev/urandomます。

ルールの例外

Cryptography Stack ExchangeのLinuxで使用/dev/randomする/dev/urandom タイミング@otusには、2つの使用例があります。

1. 低エントロピーデバイスでのブート直後、適切にシードするための十分なエントロピーがまだ生成されていない場合/dev/urandom。

2. 情報理論的セキュリティを備えたワンタイムパッドの生成

（1）が心配な場合は、で利用可能なエントロピー/dev/randomを確認できます。

あなたがやっているなら（2）あなたはすでにそれを知っているでしょう:)

注：/ dev / randomからの読み取りがブロックされるかどうかを確認できますが、競合状態の可能性に注意してください。

代替：どちらも使用しないでください！

また、@ otus は、初期シードエントロピーが利用できない場合にのみgetrandom()システムが読み取り、/dev/urandomブロックすることを指摘しました。

使用に変更/dev/urandomすることに関する問題getrandom()がありますが、新しい/dev/xrandomデバイスがに基づいて作成されると考えられますgetrandom()。

マックOS

ウィキペディアが言うように、それは重要ではありません ：

macOSは、SHA1に基づく160ビットYarrowを使用します。/ dev / randomと/ dev / urandomに違いはありません。どちらも同じように動作します。AppleのiOSもYarrowを使用しています。

FreeBSD

ウィキペディアが言うように、それは重要ではありません：

/dev/urandomは単にリンクで/dev/randomあり、適切にシードされるまでブロックするだけです。

つまり、ブート後、FreeBSDは、十分なシードエントロピーが収集されるまで待機して、終わりのないランダムな良さのストリームを配信するのに十分なほど賢いということです。

NetBSD

適切な初期シードを確実にするために/dev/urandom、システムが少なくとも1回読み取りを行っていると仮定して、を使用します/dev/random。

RNDは（4）のマン氏は述べています：

/dev/urandom ブロックしないでください。

/dev/random時々ブロック。システムの状態が予測可能であることがわかっている場合、起動時に早期にブロックします。

暗号化キーやシミュレーションのシードなど、ランダムに生成されたデータが必要な場合、アプリケーションは/ dev / urandomから読み取る必要があります。

システムは、キーを予​​測どおりに生成することを避けるために、インターネットと通信するか暗号化を必要とするサービスを実行する前に、起動時に/ dev / randomから少なくとも1回慎重に読み取るように設計する必要があります。

伝統的に、との間の唯一の違いは/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のシード。/dev/urandomRSA鍵を生成するときに使用した結果が十分なエントロピーを持たないことを説明する非常に良い論文があります。PsとQsのマイニングをお読みください。

これはやや「私も」答えですが、トム・ヘイルの勧告を強化します。Linuxに真に適用されます。

• つかいます /dev/urandom
• 使用しないでください /dev/random

Linux Kernel CryptoメーリングリストのTheodore Ts'o /dev/randomは、10年間廃止されました。以下からの再：[RFCパッチV12 3/4] Linuxの乱数ジェネレータ：

実際には、誰も/ dev / randomを使用しません。本質的に廃止されたインターフェースです。10年以上にわたって推奨されてきた主なインターフェイスは/ dev / urandomであり、現在はgetrandom（2）です。

定期的にテストし/dev/random、頻繁に障害が発生します。このテストでは、3つの手順を実行します。（1）/dev/random非ブロックモードで10Kバイトを要求することにより排出します。（2）ブロックモードで16バイトを要求します。（3）ブロックを圧縮して、ランダムかどうかを確認します（貧弱な人のテスト）。テストの完了には数分かかります。

Debainシステム（i686、x86_64、ARM、およびMIPS）では問題がひどいため、GCC Compile Farmにrng-toolsテストマシン用のパッケージをインストールするように依頼しました。gcc67およびgcc68のrng-toolsのインストールから：

rng-toolsをgcc67とgcc68にインストールするようにリクエストしたいと思います。それらはDebianシステムであり、デバイスを使用するライブラリをテストするときにrng-toolsを使用しないと/ dev / randomがエントロピーの枯渇を被ります。

BSDとOS Xは問題なく表示されます。問題は間違いなくLinuxです。

Linuxはジェネレーターの障害をログに記録しないことにも言及する価値があります。彼らはエントリがシステムログをいっぱいにすることを望んでいませんでした。現在まで、ほとんどの障害はサイレントであり、ほとんどのユーザーに検出されません。

カーネルは少なくとも1つのエラーメッセージを出力するため、状況はまもなく変化するはずです。無音コンパイラの警告及び修正のレース：[PATCH]ランダムカーネル暗号メーリングリスト上：

具体的には、を追加しましたdepends on DEBUG_KERNEL。これは、これらの有用な警告が他のカーネル開発者を突くだけであることを意味します。これはおそらくまさに私たちが望むものです。関連するさまざまな開発者が特定のサブシステムから警告を受け取った場合、それを修正する意欲が高まります。通常、ユーザーはDEBUG_KERNELを使用していないため、ディストリビューションカーネルの通常のユーザーには警告やスパムはまったく表示されません。

セキュリティエンジニアリングの観点からすべてのメッセージを抑制することは悪い考えだと思います。

多くの人は、デバッグカーネルを実行しません。問題を知りたい、または問題を知る必要があるユーザーのほとんどは、問題の発生を認識しません。systemdの問題を知った理由はdmesgのせいだと考えてください。

すべての構成のすべてのメッセージを抑制すると、必要以上に広いネットがキャストされます。潜在的に検出および修正される可能性のある構成は、おそらく見過ごされます。問題が明らかにされない場合、それは修正されません。

一部の組織では、カーネルがポリシーを決定しているように感じます。事実上修正不可能なハードウェアを持っている人にとって、組織はリスクの逆境に基づいて何をすべきかを決定する必要があります。彼らはリスクを抱えて生きることを決めるかもしれませんし、ハードウェアを更新するかもしれません。しかし、問題に関する情報がなければ、彼らは自分たちが実行可能なアイテムを持っていることに気付かないかもしれません。

妥協点はスレッドの後半で最終的に到達し、呼び出しモジュールごとに少なくとも1つのdmesgでした。