Replay Attacks in Provably Fair Poker: Why Old Proofs Must Not Work Twice

When people search for replay attacks in provably fair poker, they are usually asking a practical question: could an old valid proof be reused to make a new hand look fair? In security language, a replay attack means a valid message or proof is captured and used again in the wrong context.

For online poker, the risk is not that one word like nonce magically fixes everything. The real issue is whether each hand is bound to its own time, table, players, commitments, counters, and reveal data. A fair shuffle proof should work for one exact hand, not as a reusable coupon.

What a replay attack means

OWASP describes replay protection in terms of unique values, timestamps, and established checks that stop an old message from being accepted again: OWASP replay vulnerabilities. In plain terms, a system should know whether a message belongs to this moment or to some earlier one.

Poker fairness proofs have a similar need. A shuffle transcript may contain commitments, seeds, nonces, card reveals, action order, and hand identifiers. If those pieces are not tied together, a dishonest or broken system could present evidence from one context as if it belonged to another.

This is why a proof should answer more than "does the hash match?" It should answer "does this hash match this hand, this table, this counter, and this reveal window?"

Why poker proofs need context

A single poker hand has several moving parts. Players sit down, the hand number advances, blinds are posted, random inputs are collected, cards are dealt, actions happen in order, and private information is revealed only when appropriate. Verification should preserve that order.

For example, a server seed commitment may be valid, but that does not prove it was meant for the hand you are checking. The proof also needs a hand ID, a unique counter, and a clear connection between the commitment and the later reveal. The basics are covered in commit-reveal poker shuffle.

The same idea applies to player contributions. If a player seed, browser random value, or action signature can be replayed in another hand, the transcript becomes weaker. Strong systems make each contribution specific to one hand and one step.

Nonces, counters, and fresh randomness

NIST's glossary defines a nonce as a value used only once in a particular setting: NIST nonce glossary. In poker, that usually means a hand counter, shuffle step counter, reveal counter, or another value that should not repeat in the same protocol.

A nonce does not need to be secret. It needs to be unique where uniqueness matters. A public hand number can be useful if the proof clearly includes it. A hidden random seed can be useful if it is committed before play and revealed at the right time. These jobs are different, and mixing them up leads to bad explanations.

Fresh randomness also matters. Browser systems often use Web Crypto APIs for strong random values; MDN documents crypto.getRandomValues() as filling arrays with cryptographically strong random values: MDN getRandomValues. For the poker side, read nonce in provably fair poker.

What players can check

Most players do not need to audit every line of source code. They can look for simple signs that an old proof cannot be reused:

• Each hand has a stable hand ID or receipt
• The proof includes a unique nonce or counter
• Commitments are recorded before the reveal
• Reveals are tied to the same hand and table
• The verifier rejects missing, duplicated, or out-of-order steps
• The site explains limits, including bots and collusion

If a poker site only shows a final green checkmark, that is weak evidence. A better system gives enough information to replay the proof and see where every value belongs. For a player-friendly checklist, see provably fair poker checklist.

The honest limit

Replay protection helps keep fairness evidence tied to the correct hand. It does not stop every kind of cheating. Players can still collude outside the table. Accounts can still be stolen. Bots can still require separate detection. That is why cryptographic fairness and anti-cheat work belong together.

The practical standard is simple: an old valid proof should not be valid for a new hand. If the transcript makes that clear, provably fair poker becomes easier to verify and harder to fake with recycled evidence.