Seeding and state attacks

A software generator is only as unpredictable as the seed that starts it and the state it carries between draws. This chapter follows the randomness back to its source — seeding and entropy — and sets out the classes of attack that target the seed and the internal state: state reconstruction from observed outputs, and seed prediction. It explains the attack classes conceptually, why the standards forbid the conditions that enable them, and why none of this makes a certified game predictable in normal play.

The opening chapter established the shape of a software generator: an internal state, an update rule that advances it, and a seed that sets the state at the start. It also let you break a deliberately feeble generator by reconstructing its state from a few outputs. This chapter follows that thread to its root. If a pseudorandom generator is deterministic — same seed, same sequence — then all of its unpredictability has to enter somewhere, and everything an attacker might target lives at those two points: the seed and the internal state. Understanding the attack classes that aim at each is the clearest way to understand why the standards are written the way they are. Nothing here is a method; each section explains a class of weakness and the requirement that closes it.

Where the randomness actually enters: seeding

A pseudorandom generator manufactures no randomness of its own. NIST is explicit that “the outputs of a PRNG are typically deterministic functions of the seed; i.e., all true randomness is confined to seed generation”. So the seed has to be drawn from real unpredictability — an entropy source. As the opening chapter described, that source is physical: GLI-11 lists hardware randomness derived “from small-scale physical events such as electric circuit feedback, thermal noise, radioactive decay, photon spin”. That entropy is used to build the seed, the seed sets the internal state, and from there the generator is deterministic. NIST’s deterministic-generator recommendation states the security consequence in one sentence: the seed “must contain sufficient entropy to provide an assurance of randomness”, and “if the seed is kept secret, and the algorithm is well designed, the bits output by the DRBG will be unpredictable.”

Two ideas do all the work here, so it is worth separating them cleanly. The seed is the value that starts the generator. The internal state is what the generator carries forward and updates on every draw — early on it is a function of the seed, but it moves with each output. Both must stay secret; NIST makes the point directly: “The entropy input and the seed shall be kept secret. The secrecy of this information provides the basis for the security of the DRBG”. The two attack classes in this chapter simply target one point each — the seed at the start, or the state thereafter.

Why bad seeding breaks everything

Because a pseudorandom sequence is fixed once the seed is chosen, a seed drawn from a low-entropy or predictable source poisons the entire output. The textbook mistake is seeding from the clock: a timestamp carries very little entropy and an attacker who can bound the seeding moment to a narrow window has only a small set of candidate seeds to consider. No cryptography is broken — the starting point was simply guessable, and a guessable start to a deterministic process is a guessable whole. This is why GLI-11 does not leave seeding to good intentions. It requires that the seed “shall be randomly determined by an uncontrolled and unpredictable event”, that the pool of possible seeds be large enough to keep outcomes independent, and — for cryptographic generators — that the RNG “must not be seeded from a time value alone”. That single clause forecloses the most common amateur error outright.

State-reconstruction attacks

The second attack class assumes the seed is out of reach and goes after the running state instead. The idea, in general terms, is the one the opening chapter’s explorable demonstrates in miniature: observe enough outputs of a weak generator, use them to solve for the internal state that must have produced them, and — because the update rule is deterministic — roll that state forward to anticipate what comes next. The weak-LCG explorable pins its state from six samples for exactly two reasons: the state is tiny and the update rule is simple and reversible. Neither condition holds for a real generator, and the standards are written to guarantee that.

NIST frames the same class abstractly in terms of a state compromise. Its deterministic-generator recommendation walks through what an adversary who learns an internal state can do against a naive design: “If the adversary also knows the DRBG mechanism used, he then has enough information to compute” the following states — that is the whole attack, stated as a property rather than a recipe. The defence is a design requirement, not a patch: a cryptographic generator must provide backtracking resistance, which NIST defines so that “a compromise of the DRBG internal state has no effect on the security of prior outputs,” and, when required, prediction resistance, so that “a compromise of the DRBG internal state has no effect on the security of future DRBG outputs”. GLI-11 encodes the operational version of the same idea: it requires the generator to keep modifying its state between games — listing “background cycling” (discarding an unpredictable number of values) and re-seeding from an entropy source — so a game is never resumed from a state an observer could have been tracking.

Seed-prediction attacks

The seed-side mirror image is to skip the state entirely and predict or influence the seed. If the seeding event is guessable, constrainable, or drawn from too small a pool, an attacker can enumerate the plausible seeds and reproduce the sequence from the beginning. This is the same failure the seeding requirements above are meant to prevent, viewed from the attacker’s side rather than the designer’s: the pool must be large, the event must be genuinely uncontrolled, and the value must never reduce to something as thin as a clock reading.

This class is not hypothetical. The documented cases in the failures chapter turned on precisely this kind of predictability — approved machines whose generators leaked their future once their behaviour had been observed and reconstructed — and modern requirements read as a direct response to them. The lesson those cases teach is the one this chapter is built around: the danger was never that the payout mathematics was dishonest, but that the generator behind it was predictable, which is a property of seed and state, not of the paytable.

Why none of this makes a certified game beatable

It is important to be exact about what these attack classes do and do not imply. Every one of them targets a weak or misused generator: a small state, a reversible update rule, a guessable seed, a state left static between draws. A certified production RNG is engineered to have none of those properties — it uses a cryptographically strong generator seeded from a hardware entropy source, and it is tested precisely to preclude the conditions these attacks require. GLI-11’s cryptographic-RNG bar states the target property directly: the generator must resist a “Direct Cryptanalytic Attack: given a sequence of past values produced by the RNG, it shall be computationally infeasible to predict or estimate future RNG values”. NIST states the same thing as forward unpredictability: “if the seed is unknown, the next output number in the sequence should be unpredictable in spite of any knowledge of previous random numbers in the sequence”.

So this chapter is not a claim that a player can watch a certified slot and predict its next spin — that is exactly the outcome the standards are constructed to make computationally infeasible, and it is not a method you could act on. It is a map of the attack classes the requirements are answering, and of why a guessable seed or a recoverable state would be fatal if a generator had them. What a certificate actually vouches for, and where its statistical pass stops short of adversarial resistance, is the subject of what a certificate asserts; why statistical testing alone cannot settle predictability is covered in what RNG tests can and cannot prove. Read together, they make the same honest point from three sides: the reassurance is real because the conditions these attacks need are the exact conditions the standards forbid.

Common questions

Sources (4)

• GLI-11 Gaming Devices, v3.0 (2016) — §3.5 seeding requirements (unpredictable seed, no time-only seed, state modification) and §3.6 cryptographic RNG attack resistancegaminglabs.com
• NIST SP 800-90A Rev. 1 — Recommendation for Random Number Generation Using Deterministic RBGs (§7.1 entropy input secrecy; §8.8 backtracking and prediction resistance under internal-state compromise)nvlpubs.nist.gov
• NIST SP 800-22 Rev. 1a — A Statistical Test Suite for Random and Pseudorandom Number Generators (§1.1: PRNG determinism and forward unpredictability)nvlpubs.nist.gov
• iGamer — How casino RNGs work (the seed-and-state model and the weak-LCG explorable this chapter extends)igamerhq.com

Education, not advice. This chapter explains how the random number generators behind casino games are built, tested and certified so you can judge the claims made about them honestly. It is not a system, and nothing here treats gambling as a way to make money — over enough play the mathematics favours the house. 18+.