Hash-DRBG、HMAC-DRBG、CTR-DRBGの内部

3つのNIST DRBGメカニズムはそれぞれ、基盤となるアルゴリズムの方式を反映した異なる内部状態コンポーネントを保持します。Hash_DRBGはV（ハッシュ長のシード）とC（Vから導出され、出力生成時に使用される定数）を格納します。HMAC_DRBGはKey K（ハッシュ長の秘密鍵）とValue V（ハッシュ長の連鎖値）を格納します。CTR_DRBGはKey K（AES鍵）とV（ブロック長のカウンター）を格納します。3つすべてが、最後のシード以降のgenerate呼び出し回数を追跡するreseed_counterを保持します。状態のサイズがメモリフットプリントを決定します：SHA-256を使うHash/HMAC_DRBGの状態は64バイト、AES-256を使うCTR_DRBGは48バイト（32バイトの鍵＋16バイトのカウンター）です。

Hash_DRBGはHash_df（ハッシュ導出関数）を使用して、エントロピー素材から状態を導出します。Hash_df(input_string, no_of_bits_to_return)は、次の反復を行います：counter = 1, 2, ... のそれぞれについて、H(counter || no_of_bits || input_string)を計算し、必要なビット数が得られるまで出力を連結します。これにより、短いエントロピー入力が状態サイズのシードに引き伸ばされます。Generate中、出力関数はW = H(0x03 || V)を計算します。この0x03プレフィックスは、これを他のハッシュ用途と区別します。出力ループは次のとおりです：data = H(0x01 || V); V = V + 1; さらに出力する場合は繰り返します。生成後、Vは次のように更新されます：V = V + H(0x03 || V) + C + reseed_counter。プレフィックスバイト（0x01、0x03）によるドメイン分離により、生成フェーズの出力が状態更新フェーズの出力と混同されるのを防ぎます。

HMAC_DRBGのUpdate関数は、すべての状態遷移の中核です。Update(provided_data, K, V)：K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V)。provided_dataが空でない場合：K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V)。この2段階の更新により、新しい鍵と値の両方が、以前の状態と新しいエントロピーに依存することが保証されます。Generateでは、十分なビット数が生成されるまでV = HMAC(K, V)をループして出力に追加し、その後additional_inputを指定してUpdateを呼び出し、状態を前進させます。HMAC_DRBGの安全性は、HMACが安全なPRFであるという仮定に帰着します：HMACの出力と乱数を見分けられない攻撃者は、DRBGの出力と乱数も見分けられません。

CTR_DRBGはBlock_Cipher_df（導出関数）を使用して、シード素材を鍵／カウンター形式に変換します。Block_Cipher_df(input_string, no_of_bits)はBCC（Block Cipher Chaining）構造を使用し、入力チャンクに対してAES-CBCを反復適用して、必要な長さの出力を生成します。この導出関数は、可変長のエントロピー入力を扱い、ドメイン分離を提供するために必要です。導出関数を使用しないCTR_DRBG（正確に整形された入力を使うFIPSテストで許可されます）は高速ですが、入力形式の要件により敏感です。Generateループは次のとおりです：temp = E(K, V); V = V + 1; tempを出力に追加します。Update：K || V = Block_Cipher_df(V || additional_input, seedlen); 現在の鍵とのXORを適用します。

性能はDRBGの種類によって大きく異なります。AES-NIを備えた最新のx86_64 CPUでは、CTR_DRBG（AES-256）は疑似乱数出力を約5～10 GB/sで生成します。AES-NI命令により、AESの計算コストがほぼ無視できるためです。HMAC_DRBG（SHA-256）は約200～400 MB/sを達成します。SHA-256は高速ですが、同程度にはハードウェアアクセラレーションされません。Hash_DRBG（SHA-256）は約100～300 MB/sを達成します。大量の鍵生成やストリーム暗号の代替では、CTR_DRBGが圧倒的に高速です。セッション鍵の生成やnonceの導出などスループットが低い用途では、性能差は無視できます。OpenSSL 3.0がこの理由でCTR_DRBG（AES-256）をデフォルトにしています。

インスタンス化時、3つすべてのDRBGはオプションのpersonalization_stringを受け取り、エントロピー入力と混合してDRBGインスタンスを一意にします。これにより、同じエントロピーで同時にインスタンス化された2つのDRBGが同じ出力を生成するのを防ぎ、personalization_stringに基づいて異なる状態に分岐します。推奨されるpersonalization_stringは、アプリケーション識別子 + プロセスID + スレッドID + タイムスタンプ + ハードウェア識別子です。同じエントロピーを2つのVMが受け取った場合でも（クラウドVMのスナップショット問題）、異なるpersonalization_stringによって異なるDRBGストリームが保証されます。NIST SP 800-90Cは、常にpersonalization_stringを使用することを推奨しています。nonceパラメータも同様の目的を持ちます。これは、2つのインスタンス化が同じ状態で開始しないようにする一意の短い値です。

3つすべてのDRBGは、Generate呼び出しのadditional_inputパラメータをサポートします。これにより、完全な再シードを行わずに、呼び出し元が1回のGenerate呼び出しへ追加のコンテキストやエントロピーを注入できます。用途：(1) 2次的なエントロピー源からリクエストごとのエントロピーを注入すること。(2) 生成値をその用途に結び付けるため、アプリケーションレベルのコンテキスト（リクエストID、タイムスタンプ）を提供すること。(3) OSから新鮮なエントロピーを注入して、オプションの予測耐性を提供すること。additional_inputは、出力生成前にDRBGの状態へ混合されます。additional_inputが実際のエントロピーを提供する場合、エントロピー源インターフェースとそれに伴うオーバーヘッドを含む正式な再シードを必要とせずに、セキュリティを向上させます。

DRBGのインスタンスが破棄された後（または新しいインスタンスに切り替えるとき）は、内部状態を安全にゼロ化する必要があります。状態V、C（Hash_DRBG）、K、V（HMAC/CTR_DRBG）、およびすべての中間作業変数をゼロで上書きします。これは明示的なゼロ化と呼ばれ、FIPS 140-3モジュールでは必須です。Cコードでは、explicit_bzero()またはSecureZeroMemory()を使用してください。コンパイラに最適化されたmemsetは、不要なストアの最適化によって削除され、メモリ上に鍵素材を残す可能性があります。Rustのzeroizeクレートや同様の言語固有の解決策は、これを移植性のある形で処理します。メモリダンプ、コールドブート攻撃、またはプロセス検査ツールによって残存状態が露出する可能性がある状況では、安全な鍵の破棄が重要です。

NISTは、すべてのSP 800-90A DRBGに対するCryptographic Algorithm Validation Program（CAVP）のテストベクトルを提供しています。テストの種類：(1) Known Answer Tests（KATs）— 固定されたエントロピー入力、nonce、personalization_stringを与え、生成出力が事前計算値と一致することを検証します。(2) 再シードテスト — 再シード操作後のDRBG状態を検証します。(3) PR（Prediction Resistance）テスト — prediction_resistance=trueを要求したとき、新しいエントロピー注入後に正しい出力が生成されることを検証します。CAVP検証はFIPS 140-3申請に必要です。オープンソースライブラリ（OpenSSL、mbedTLS）は、DRBG実装のリグレッションを検出するため、リグレッションテストスイートにCAVPテストベクトルを含めています。

DRBG実装は、アルゴリズムのセキュリティモデルを超えた、微妙なサイドチャネルリスクに直面します。AES（AES-NIを使用しないCTR_DRBG）へのキャッシュタイミング攻撃によってラウンド鍵の素材が漏洩する可能性があります。AES-NIは、テーブル参照を使わずレジスタ内で計算することでこれを排除します。HMAC_DRBGは内部でHMACを使用します。基盤となるSHA-256が定時間であれば、HMACも定時間です。SHA-256にはデータ依存の分岐がないため、一般に定時間と考えられています。物理的なサイドチャネル（電力解析、電磁波放射）によるDRBG生成ハードウェアへの攻撃は、スマートカードやIoTデバイスで懸念される問題であり、マスキング実装によって対処します。状態バックアップ攻撃：攻撃者がメモリ情報漏洩の脆弱性（Heartbleed型）を介してDRBG状態を読み取れる場合、新しいエントロピーによる次回の再シードまで、将来のすべての出力が侵害されます。

DRBG状態が侵害された場合（たとえばメモリ情報漏洩の脆弱性による場合）、復旧には次が必要です：(1) 侵害を検出すること — DRBG状態の漏洩は自明ではないため、外部監視または完全性チェックが必要です。(2) 侵害に関与していない信頼できるソースから新鮮なエントロピーを用いて再シードすること。(3) 侵害されたDRBGから導出されたすべての暗号素材（セッション鍵、最後に健全な再シードを行ってから生成された署名鍵）を再鍵化すること。(4) ソフトウェア実装では、プロセスを再起動してDRBGをクリーンな状態でインスタンス化します。SP 800-90Cは連鎖したエントロピー源を推奨しています。1つのソースが侵害された場合でも、もう一方のソースが実際のエントロピーを提供すれば、組み合わせによって安全性が確保されます。

現代のCPUで大量の疑似乱数出力を生成する場合、最も高速なDRBGメカニズムはどれですか？

Hash_DRBGは、導出にHash_dfを用いた反復ハッシュを使用し、H(0x01 || V)のループで出力を生成します。HMAC_DRBGはPRFとしてHMACを使用し、鍵、次に値を更新する2段階のUpdate関数によって、明快な安全性の帰着を実現します。CTR_DRBGはBlock_Cipher_dfを用いたカウンターモードのAESを使用し、AES-NIハードウェア上で5～10 GB/sを達成します。3つすべてが、インスタンスの一意性のためにインスタンス化時のpersonalization_stringを、コンテキストを結び付けるために生成ごとのadditional_inputを受け付けます。CAVPテストベクトルが実装を検証します。状態は使用後に安全にゼロ化する必要があります。状態が侵害された場合は、新鮮なエントロピーによる再シードと、導出された素材の再鍵化が必要です。