PRNGで収集されるエントロピーを評価する
組み込みデバイスの乱数ジェネレーター（暗号品質であると予想される）を確認しています。ここでの私の見解は、オペレーティングシステムと暗号ライブラリの実装者です。私は特にエントロピー収集について心配しています。確認するポイントをいくつか確認しました。
- PRNGの初期状態はどのように生成されますか？
- PRNGは、エントロピーが増えるまで配信を拒否する必要がありますか？
- より多くのエントロピーを注入するAPI呼び出しがありますが、新しいエントロピーと既存の状態をどの程度うまく混合していますか？
（私の場合、ハードウェアRNGがあり、体系的に使用するには遅すぎますが、そこからエントロピーを得ることができます。）
私の実装が適切である場合、これらの質問に対する回答はどのように見えるべきですか？他にどのような質問に答える必要がありますか？
「エントロピー」は、一部のデータ要素がどのようなものであったかを示す尺度です。 nビットのエントロピーは、それらのビットが集合的にと仮定できる場合、ビットの束の中にあると言います。 2ん一様な確率で値を区別します（「一様」という用語の下に隠れている複雑さがたくさんあります）。暗号的に安全なPRNGを作成するには、次のことを行う必要があります。
- ランダムソースから十分なデータを収集して、少なくとも128ビットのエントロピーに到達するようにします。 2のスペースの無視できない部分を「試行」することは、攻撃者にとって実現可能であってはならないという考えです。ん可能な内部状態。 n = 80はそのための従来の値でしたが、80年代以降の技術的進歩を考えると、n = 128、これは2の累乗であり、したがって神から祝福されます。
- そのエントロピーを含んだシードを適切なストリーム暗号のような関数で使用します。これは、初期鍵に基づいて疑似ランダムビットを出力する関数です。ここでは、キーは、固定長の出力を持つ一方向関数（つまり、ハッシュ関数）を介してシードから派生します。ここで探しているセキュリティ特性は、連続する出力ビットのシーケンスが与えられた場合、成功確率が0.5を大幅に上回る他の過去または将来の出力ビットを推測することができないことです。 「未来のビット」の部分に注意してください。これは、あなたが考えるほど迅速ではありません。
第二のポイントは簡単ではありません。基本的なルールとして、ストリーム暗号のような関数が、いくつかの標準で正確に記述され、何十人もの暗号技術者によって分析されている公開された構造ではない場合、PRNG as疑わしい品質である。自家製PRNGは自家製ブロック暗号と同じくらい悪い：それは強いかもしれないが、多くの自家製PRNGは強くないで、暗号強度の確実なテストはありません。
NISTはいくつかの完全な説明を公開しました "approved" PRNG 。 PRNG使用するものがその1つである場合、それは問題ありません。それ以外の場合は、本当に警告フラグを立てる必要があります。
あなたの正確な質問については：
最初のPRNG=状態は、「good alea sources」から収集する必要があります。つまり、ソースは「変化する」データを生成するだけでなく、攻撃者が変更を監視できないようにする必要があります。たとえば、「ping」リクエストを外部ネットワークホストに送信し、応答が返されるまでにかかった時間を測定することは、ない良い情報源です：確かにランダムに見えますが、攻撃者があなたの発信ICMP要求と対応する応答を観察し、同じタイミング測定値を得ることができると想定する必要があります。そのような質問のより詳細な扱いについては、 この答え （はい、私は自分自身を引用しています）。
追加のエントロピーの注入は、初期状態の注入と非常に似ています。「ランダムデータ」は、しばしばかさばる場合にシードとして使用されるため、高エントロピーを生成するための混合ステップが必要ですshortシーケンス。ここでのツールは、安全なハッシュ関数です。単純にするために、注入は次のようになります。現在の内部状態を取得し、追加の「エントロピー」を連結して、全体をハッシュします。ハッシュ出力は新しい状態です。注意：この種のことは、特定のハッシュ関数に対して正確に保証されていないセキュリティプロパティに依存しています。ここで私が意味することは、そのような使用法に対して安全であることは、衝突やプリイメージ耐性があるという結果ではないということです。したがって、そのためにハッシュ関数を使用すると、ある種の信頼が高まります（たとえば、SHA-256を使用するよりも悪い場合もあります）。 NIST PRNGでは、そのようなジョブに [〜＃〜] hmac [〜＃〜] を使用するHMAC-DRBGをよく見ることをお勧めします。 HMACは メッセージ認証コード であり、同様の理由でより優れた「セキュリティ証明」を可能にする方法で、基礎となるハッシュ関数を使用します。
PRNGより多くのエントロピーが得られるまで、より多くのデータを配信することを拒否するという考えは、少しブードゥーの儀式です：それを信じている場合にのみ重要です。PRNGランダムな十分な初期シードを使用し、適切なデータ生成関数を使用した場合、ペタバイト単位の疑似エリアを生成することでセキュリティ上の問題は発生しません。ただし、一部の人々は緊張し、 PRNG実装にはブロッキング動作が含まれ、PRNGは、128ビットの初期エントロピーから1 MB以上のデータを出力することを拒否します。練習、ブロッキングPRNG（初期化を超えて-十分なinitialエントロピーが収集されるまでブロックする必要があります）展開の問題につながります（たとえば、ユーザーからエントロピーを収集するためのキーボードまたはマウスがないため、SSHキーの生成に関しては、サーバー上でブロックするLinux OS自動インストール）。
a。 PRNG標準状態として実行します（ NIST SP 800-9 を参照））;
b。標準で特に明記されていない限り、完全な初期シードを取得している限り、ブロックしないでください。
Linuxの
/dev/randomと/dev/urandomはどちらも失敗することに注意してください：/dev/randomは頻繁にブロックし、/dev/urandomはまったくブロックしませんそれも良い初期シードを取得しなかった場合でも。幸いなことに、適切なLinuxディストリビューションであれば、/dev/urandomがブートスクリプトの一部として十分なシードで初期化されます（前回のシャットダウン時に生成された隠しファイルにランダムシードを保持することを含む）。 FreeBSDの/dev/urandomは、私が説明したとおりに動作し、それは良いことです。
主な質問はすでに回答されているので、私は回答の一部を拡大しています。
一部のエントロピーソースが盗聴されたり、攻撃者によって完全に制御されたりする可能性があるエントロピー収集は、正しく行うのがやや難しい作業です。収集されたエントロピーの量を見積もると、失敗する運命にあります。
これらの問題を解決するための適切な実装は Fortuna です。 Bruce Schneierらによって設計されました。