CSPRNG

ウォレット用の秘密の値を作るプログラムを考えてみましょう。攻撃者が過去の出力の一部を知ったとしても、安全な生成器なら、それを手がかりに残りを推測しやすくなってはいけません。これは、グラフ上で数字がきれいに分布することより厳しい条件です。RFC 4086も、暗号学的に強い列と一般的なシミュレーション用生成器を区別しています。統計検定の結果が良くても、生成の出発点であるseedを推測できるなら不十分です。 [1]

技術文書にはDRBG、つまり決定論的乱数ビット生成器という名称も出てきます。「決定論的」とは、内部状態と入力が同じなら結果も同じになるという意味です。そのため、状態は秘密に保たなければなりません。NIST SP 800-90A Rev. 1は、Hash_DRBG、HMAC_DRBG、CTR_DRBGという具体的な方式を定めています。これらは技術的な手順であり、名前を使うすべてのソフトウェアへの品質認証ではありません。設定、エントロピーの由来、実際のコードも確認が必要です。 [2]

状態の漏えいでは、二つの別の問題が生じます。攻撃者は過去の秘密の出力を再計算できるでしょうか。そして、次の出力を予測できるでしょうか。過去の出力を守る性質をBacktracking resistance、将来の出力を守る性質をPrediction resistanceと呼びます。後者についてNIST SP 800-90Aは、新しいエントロピーを効果的に取り込み、漏れた状態から新しい結果を切り離すことを求めています。単に計算をもう一度実行しても、安全性が回復するとは限りません。一方の保護があっても、他方まで自動的に保証されるわけではありません。 [2]

ライブラリーは、ウォレットが利用できる既成のソフトウェア部品です。ただし、その呼び出しも失敗します。OpenSSL 3.5のRAND_bytes()とRAND_priv_bytes()は、成功時に1、その他の失敗時に0、現在の方式が未対応なら-1を返します。エントロピー源が故障すれば、生成が拒否される場合があります。プログラムは、バッファーと呼ばれる確保済みのメモリー領域を使う前に、この戻り値を確認しなければなりません。そうしないと、安全に生成されていないデータを利用するおそれがあります。 [3]

再現性はテストで役立ちます。開発者は結果を期待値と比較したいからです。libsodiumのrandombytes_buf_deterministic()は、そのため同じseedから同じ列を作ります。しかし通常の運用では、意図しない繰り返しが問題になります。仮想マシンのスナップショットは、メモリーを含むコンピューターの状態を保存したものです。復元時には生成器の状態や出力まで繰り返す可能性があります。環境を複製しても、独立した秘密が得られるとは限りません。 [4]

生成器が良い乱数を提供しても、アプリがその後の処理を誤ることがあります。許された小さな範囲に数値を収めるため単純に割り算の余りを使うと、ある結果がほかより出やすくなる場合があります。libsodiumのrandombytes_uniform()は、指定した上限未満から一様に選ぶことで、この偏りを避けます。鍵には、使用するアルゴリズム固有の規則もあります。ランダムなバイトを得て終わりではなく、その後の使い方まで安全性を左右します。 [4]

Nonceは、暗号処理の個々の使用に向けた値ですが、守るべき規則はプロトコルが定めます。RFC 8439では、同じ鍵でnonceを繰り返してはいけません。ランダムに見えることだけでは、一意性を保証できないからです。一方、RFC 6979は、秘密鍵と署名対象のメッセージから、電子署名に必要な値kを決定論的に計算する方法を説明しています。これは矛盾ではなく、設計の違いです。「どこにでも乱数を追加する」という方針は、正しい手順の代わりにはなりません。 [5] [6]

CSPRNGと書かれているだけでは、ウォレットが仕組み全体を正しく使っているかは分かりません。技術的な確認では、ライブラリーの具体的なバージョン、生成器の起動、エラー処理、状態の復元や複製後の動作を調べます。OpenSSLやlibsodiumの文書が示すのは、それぞれの関数の性質であって、呼び出すすべてのアプリの安全性ではありません。利用者にはその後も重要です。完全に安全な方法で作られた秘密であっても、アクセスを復元できるバックアップが後から漏れれば、資金を守れなくなります。 [3] [4]