Provably Fair Pokerのリプレイ攻撃とは：古い証明を再利用させない理由

Provably Fair Pokerで「リプレイ攻撃」を調べる人が知りたいのは、古い正しい証明が別のハンドに使い回されないか、という点です。セキュリティでは、リプレイ攻撃とは一度有効だったメッセージや証明を別の場面で再送し、システムに受け入れさせる攻撃を指します。

オンラインポーカーでは、nonce という単語だけで安全になるわけではありません。大切なのは、各ハンドの証明が、そのハンドID、テーブル、プレイヤー、コミットメント、カウンター、公開タイミング、検証手順に結び付いていることです。公平性の証明は、その一回だけに有効であるべきです。

リプレイ攻撃の基本

OWASPは、古いメッセージを再利用させないために、一意な値、タイムスタンプ、明確な検証を使う考え方を説明しています：OWASP replay vulnerabilities。つまり、システムは「これは今の処理か、それとも過去の処理のコピーか」を見分ける必要があります。

ポーカーの公平性証明でも同じです。シャッフルの記録には、コミットメント、シード、nonce、カード公開、アクション順、ハンド番号などが含まれます。これらが結び付いていないと、あるハンドの証拠が別のハンドの証拠のように見えてしまう可能性があります。

だから検証では、「ハッシュが一致したか」だけでは足りません。「そのハッシュは、このハンド、このテーブル、このカウンター、この公開期間に対応しているか」まで見る必要があります。

なぜハンドの文脈が必要か

テキサスホールデムの一ハンドには多くの段階があります。着席、ハンド番号、ブラインド、ランダム入力、配札、アクション、ショーダウン、必要な公開情報という順序があります。検証ログもこの順序を保つべきです。

たとえば、サーバーシードのコミットメントが本物でも、それだけでは確認中のハンド用だったとは言えません。ハンドID、一意なカウンター、後で公開される値との対応が必要です。基本の流れは commit-reveal poker shuffle で説明しています。

プレイヤー側の入力も同じです。プレイヤーシード、ブラウザの乱数、アクション署名が別のハンドで再利用できるなら、証明は弱くなります。強い設計では、各入力を一つのハンド、一つの手順に限定します。

nonce、カウンター、新しい乱数

NISTの用語集では、nonceは特定の文脈で一度だけ使われる値として説明されています：NIST nonce glossary。ポーカーでは、ハンド番号、シャッフル手順番号、公開番号などがこれに当たります。

nonceは秘密である必要はありません。重要なのは、重複してはいけない場所で重複しないことです。公開されたハンド番号も、証明の中にきちんと含まれていれば役に立ちます。隠されたシードは、事前にコミットされ、正しいタイミングで公開されると役に立ちます。

新しい乱数も重要です。ブラウザではWeb Cryptoが強い乱数を扱うために使われます。MDNは crypto.getRandomValues() を、暗号学的に強いランダム値を配列に入れるAPIとして説明しています：MDN getRandomValues。ポーカーでのnonceは nonce in provably fair poker も参考になります。

プレイヤーが見られる点

普通のプレイヤーがすべてのコードを読む必要はありません。次のような点を見るだけでも、証明の質はかなり分かります。

• 各ハンドに固定のハンドIDやレシートがある
• 証明に一意なnonceやカウンターがある
• コミットメントが公開より前に記録されている
• 公開値が同じハンドとテーブルに結び付いている
• 検証器が欠落、重複、順序違いを拒否する
• ボットや共謀などの限界も説明している

最後に緑のチェックだけを見せるサイトは、証拠として弱いです。より良い仕組みは、値がどこに属するかを追える検証材料を出します。確認項目は provably fair poker checklist にもまとめています。

正直な限界

リプレイ対策は、公平性の証拠を正しいハンドに固定するためのものです。ただし、プレイヤー同士の共謀、盗まれたアカウント、ボット利用までは止められません。そこには別の不正対策と安全設計が必要です。

実用的な基準は明快です。古い有効な証明は、新しいハンドでは有効であってはいけません。それが分かる記録があるほど、Provably Fair Pokerは信頼ではなく検証に近づきます。