ランダムなナンスはどのくらいの長さでなければなりませんか？
NISTは さまざまなアルゴリズムのキーとハッシュの長さに関する適切なガイドライン を提供します。しかし、ランダムまたは疑似ランダム nonce （数値は1回使用された）の長さについては特に何も見ていません。
さまざまな用途に適した答えが1つある場合は、ぜひご覧ください。ただし、これを具体的にするために、サーバーが疑似ランダムパスコンポーネントを使用してURLを生成する、一般的な「電子メールによるパスワードのリセット」の状況を使用します。 RFCの例 が136ビット（dcd98b7102dd2f0e8b11d0f600bfb0c093）を持っているように見えるHTTPダイジェスト認証に少し似ているようです。
で説明されているように、多くの人がバージョン4 UUID（122の疑似ランダムビットを提供）またはこれを使用しているようですが、GUIDはワンタイムトークンに対して安全ですか？ 、ただし、ユーザーは以前のはるかに予測可能なUUIDバージョンの使用に注意する必要があります Windows乱数ジェネレータに対する厄介なローカル攻撃 2008年までにパッチを適用。
しかし、UUIDのバージョンと実装に巻き込まれるリスクを無視して、いくつの疑似ランダムビットをURLに組み込む必要がありますか？
64ビットが暗号品質のランダム性である場合、64ビットのnonceは、ほとんどの実用的な目的にはおそらく十分すぎるほどです。
なぜ64ビットで十分なのですか？この質問に答えるために使用できる類の理由を説明しましょう。これは使い捨ての時間制限付きURLであると想定します。一度使用すると無効になり、しばらくすると（たとえば3日後）有効期限が切れて無効になります。 nonceはサーバーにとって意味があるだけなので、攻撃者が推測を試みる唯一の方法は、64ビットの推測をサーバーに送信して、サーバーがどのように応答するかを確認することです。 nonceの有効期限が切れるまでの間に、攻撃者は何回推測することができますか？攻撃者が1秒あたり1000のHTTPリクエストを行うことができるとしましょう（かなり攻撃的な攻撃者です）。その後、攻撃者は約1000 * 3600 * 24 * 3 = 2を作成できます28 3日以内に推測します。それぞれの推測には1/2があります64 正しい可能性。したがって、攻撃者は最大で1/236 スキームを破る可能性。これは、ほとんどの設定で十分に安全です。
まず、システムが使用する最大使用量（ランダムなナンスが生成される回数）を見積もります。次に、許容可能なセキュリティレベルを決定します。つまり、ナンスが古いものの複製である可能性がどれほどあり得ないかを決定します。ビット単位での使用量を計算し、それを2倍にして、ビット単位で必要な確率を追加し、ノンス長を取得します。
ランダムIVを使用したAES-GCMの例。特定のキーに対してランダムIVで許可される呼び出しの数は2です。32。 IVが再利用される確率は2未満でなければなりません-32。これに必要なノンス長は、32×2 + 32 == 96ビットです。
仮に、2を生成できるようにしたい場合96 パケットは、それぞれがランダムなナンスを持ち、ナンスが重複する確率が2未満になることを望みます。-32、96×2 + 32 == 224ビット長のnonceが必要です。
これを上記の64ビットの答えと比較すると... 2つ以上ある場合16 （65536）システムの使用、その時間内にナンスが重複する確率は2より大きい-32 （40億分の1以上、短いスケール）。これは、セキュリティ要件によっては、十分に許容できる場合とそうでない場合があります。
1つのサイズですべての答えが収まるため、前述のランダムなUUIDはかなり問題のないソリューションです。
これらの値は近似であり、より正確な計算ははるかに複雑になることに注意してください。