暗号学的擬似乱数生成器（CSPRNG） 乱数生成ツール

乱数には、二つの顔があります。ひとつは、見た目がちゃんと散っている乱数です。サイコロを何度も振ったとき、1だけがやたら多く出たら変です。コイン投げなら、表と裏が極端に偏ると気になります。抽選、順番決め、ちょっとしたシミュレーションなら、まず気にするのはこの「偏りのなさ」です。

もうひとつは、相手に見られても読まれない乱数です。ログイン用の一時コード、パスワード再設定トークン、APIで使う秘密値、セッションIDのようなものでは、「あとで見たら分布がきれい」だけでは足りません。攻撃者がいくつかの値を見ても次の値を当てられないこと、過去や未来の値を逆算できないこと、内部状態を推測できないことが必要になります。ここで必要になるのがCSPRNG、Cryptographically Secure Pseudorandom Number Generator、暗号学的擬似乱数生成器です。

OWASPは、セッションIDや安全上重要なランダム値では通常のPRNGではなくCSPRNGを使うべきだと説明しています。つまり、乱数生成ツールや乱数メーカーと呼ばれるものでも、用途が認証や権限に近づいた瞬間、必要な品質が一段変わります。

ここで少し不思議なことが起きます。「擬似」なのに、なぜ安全と言えるのでしょうか。コンピュータの乱数は、多くの場合、完全な自然現象そのものを毎回その場で読んでいるわけではありません。最初にOSなどから得た予測しにくい材料、つまりエントロピーを使って内部状態を作り、その状態を暗号学的な処理で混ぜながら、次々にビット列を出します。

状態が同じなら出力も同じになるので、数学的には決定論的です。それでも、外から見た攻撃者に内部状態が分からず、出力から次の出力を計算できないように作られていれば、実用上は「読めない乱数」として扱えます。NIST SP 800-90A Rev.1は、このようなDRBG、決定論的乱数ビット生成器の代表的な仕組みを扱います。さらに90Bはエントロピー源、90CはDRBGとエントロピー源を組み合わせたRBG構成を扱い、乱数を「作る」だけでなく「支える材料」まで分けて考えます。

このツールは、乱数生成アルゴリズムを自前で発明しているわけではありません。そこはブラウザとOSに任せます。具体的には、Web Crypto APIのcrypto.getRandomValues()で暗号学的に強いランダムバイトを取得し、UUID v4が必要なときはcrypto.randomUUID()を使います。

より正確に言うと、このツールが単独でCSPRNGそのものなのではなく、ブラウザが提供するCSPRNG相当の乱数源を利用するツールです。実際のアルゴリズムやエントロピー源はブラウザ、OS、実装に依存します。Web Cryptography仕様も、エントロピー源の情報理論的な下限を一律には決めず、実装が高品質なエントロピーでseedされた確立済みのPRNGを使うべきだとしています。

getRandomValues()には、一度に65,536バイトを超えるTypedArrayへは使えないという制限があります。このツールは内部で分割して呼び出します。randomUUID()は通常HTTPSなどのsecure contextで利用されます。getRandomValues()は例外的に非secure contextでも利用できるAPIですが、乱数生成ツール自体はページ改ざんを避ける意味でもHTTPS提供を前提に考えるべきです。

では、Math.random()ではなぜだめなのでしょうか。理由は単純で、Math.random()は便利な疑似乱数であって、暗号用途の安全性を目的にしていないからです。画面上の演出、ゲーム内のちょっとした揺らぎ、簡単な並び替えなら十分な場面があります。

しかし、秘密値や認証に関わる値では、攻撃者が次を当てにくいことが必要です。MDNもMath.random()をセキュリティ関連に使わず、Web Crypto API、より具体的にはcrypto.getRandomValues()を使うよう説明しています。ここが最初の分かれ道です。見た目のランダムさと、攻撃者に読まれないランダムさは、同じ顔をしていても別物です。

ただし、Web Crypto APIを使えばすべて終わり、ではありません。ここからが本当に大事です。たとえば、0から255まで均等に出る1バイトの乱数があるとします。これを1〜100の整数にしたいとき、単純に100で割った余りを使うとどうなるでしょうか。

256個の値を100個の箱に配ることになります。100で割り切れないので、ある箱には3個、ある箱には2個しか入りません。具体的には、0〜55に対応する値は3通り、56〜99に対応する値は2通りになります。つまり、前半の値が後半より1.5倍出やすくなります。これがmodulo biasです。

乱数そのものが強くても、最後に範囲へ押し込む変換が雑だと、出口で曲がってしまいます。強い水源からきれいな水を引いてきたのに、蛇口の先で片側だけ漏れているようなものです。

この偏りを避けるために使うのがrejection samplingです。考え方は拍子抜けするほど素朴です。範囲にきれいに割り当てられる部分だけを採用し、余った部分は捨てて引き直します。0〜255から1〜100を作るなら、0〜199までを使えば100個の値にちょうど2個ずつ対応します。200〜255が出たら採用せず、もう一度引きます。

捨てるのはもったいなく見えますが、公平さを買うための必要経費です。CSPRNGの強さを最後の整数変換まで保つには、この一手が効きます。

文字列として乱数を出すときにも、形式ごとの意味を知っておくと迷いません。HEXは1文字で4ビットを表すので、16バイト、つまり128ビットの乱数は32文字になります。読みやすく、ログや設定ファイルに貼りやすい一方、少し長くなります。

Base64は1文字で6ビットを運べるので短くできますが、通常のBase64には+や/や=が出ます。URLやAPIで扱いやすくするなら、+を-、/を_に変えたBase64URLが便利です。RFC 4648は、通常のBase64とURL・ファイル名安全なBase64URLを区別して定義しています。

UUID v4は、識別子として広く使われる形式です。crypto.randomUUID()で作れるUUID v4は、バージョンやvariantを示す固定ビットを除き、122ビット分がランダムです。これは衝突しにくい識別子としては非常に便利です。ただし、UUIDはIDであって、何にでも使える秘密の鍵ではありません。RFC 9562も、UUIDを持っているだけでアクセス権になるようなsecurity capabilityとして使うべきではないと注意しています。

トークンは、推測されにくいことが中心です。パスワードリセットURLやAPIアクセス用の一時値のように、それを知っていることが権限につながるなら、十分なエントロピー、有効期限、保存方法、失効処理が必要です。

検証コードは、短い桁数で人間が入力しやすくするため、単体ではそこまで強くありません。6桁の数字なら候補は100万通り、約20ビットです。CSPRNGで均等に作ることは大切ですが、それだけでは足りません。短時間で失効させる、試行回数を制限する、同じ相手に大量送信させない、といった運用側の守りがセットになります。

saltは、多くの場合、秘密である必要はありません。大事なのは、同じパスワードが同じハッシュに見えないようにすること、そして利用者や保存対象ごとに重複しにくいことです。CSPRNGで作るのはよい選択ですが、「saltが読まれたら終わり」という種類の値ではありません。

nonceは、名前の通り一度だけ使う値です。暗号モードによっては、予測困難性よりも同じ鍵の下で絶対に再利用しないことが決定的に重要です。ランダムnonceを使う場合でも、サイズが小さすぎれば衝突します。カウンタで管理する方が向く場面もあります。OWASPも、IVやnonceは暗号モードに応じてライブラリで扱うべき要素として説明しています。

暗号鍵については、さらに慎重に考えます。このツールでランダムなバイト列を作ること自体はできます。しかし、暗号鍵はランダムな文字列をコピーしてどこかに貼るだけで安全になるものではありません。アルゴリズム、用途、取り出し可能かどうか、保存、ローテーション、破棄まで含めて管理する必要があります。Web Crypto APIでも、鍵生成にはgetRandomValues()ではなくgenerateKey()を使うことが推奨されています。

重複なしの抽選では、さらに別の限界があります。1〜10から重複なしで11個選ぶことはできません。これは実装の問題ではなく、数学的に不可能です。このツールでは、そのような条件を静かに通さず、警告します。また、極端に広い範囲で大量の重複なし生成をすると、端末のメモリや処理時間を大きく使うため、実用上の上限も必要です。便利な乱数メーカーである前に、破綻した条件を破綻として扱うことが大切です。

このツールが守るべきことははっきりしています。Math.random()ではなくWeb Crypto APIを使う。範囲指定の整数では、単純な剰余ではなくrejection samplingで偏りを避ける。HEX、Base64URL、UUID v4の違いを説明し、用途に合った形式を選べるようにする。UUID v4を便利な識別子として扱い、万能な秘密トークンと誤解させない。salt、nonce、検証コード、tokenの安全条件を分けて説明する。重複なし生成で不可能な条件を警告する。暗号鍵そのものは、Web Crypto APIのgenerateKey()など用途別APIを推奨する。

最後に、乱数生成ツールのいちばん大事なオチを置いておきます。安全な乱数は、「強いAPIを呼んだ」という一点だけでは決まりません。強い乱数源を使う。範囲変換で偏らせない。短いコードには試行制限を付ける。nonceは再利用しない。UUIDを秘密値だと思い込まない。鍵は鍵として管理する。

乱数は、入口より出口で失敗しがちです。CSPRNGを使う意味は、乱数の水源を強くすることだけではありません。その水を、最後の一滴まで曲げずに届けることです。