How computers make random numbers

Every recipe falls into a loop.

Run a few seeds and you will see the pattern that doomed the middle-square method. Some seeds collapse within a handful of steps — 2100 goes to 4100, 8100, 6100 and back to 2100 for ever. Others wander for a while before snagging. None escape. We ran all 10,000 four-digit seeds while writing this: every one ends in a loop, 2,263 of them freezing on a single number and the rest circling through four. The longest run before a repeat, from seed 6239, is 111 steps.

That is the fate of every recipe of this kind, not just this one. A computer generator has a finite memory, so it can only be in so many states; sooner or later it must revisit one, and from then on it repeats. The best anyone can do is make “sooner or later” astronomically late and make the sequence pass every test for randomness until then. These are pseudo-random numbers: a performance of chance, not the thing itself.

Better recipes, and a famous bad one.

The next idea was the linear congruential generator: multiply the previous number by a constant, add another, keep the remainder. Done well it was good enough to run the computing world for decades. Done badly it produced RANDU, the routine IBM shipped with its System/360 machines in the 1960s: multiply by 65,539, keep the remainder modulo 2³¹. Plot three consecutive RANDU outputs as a point in space and every point lands on one of just fifteen flat planes. George Marsaglia exposed the problem in 1968 in a paper whose title says it all — “Random Numbers Fall Mainly in the Planes”.

Donald Knuth opened the random-numbers chapter of The Art of Computer Programming with his own cautionary tale: a deliberately complicated “super-random” recipe that almost immediately settled on a number that turned back into itself. His moral, as it is usually quoted: random numbers should not be generated with a method chosen at random. Twenty years later Stephen Park and Keith Miller were still pleading the case in a paper titled “Random number generators: good ones are hard to find”, and proposed a “minimal standard” — multiply by 16,807 modulo 2³¹ − 1 — as a floor nobody should fall below.

Fine for games. Not for secrets.

Here is the line that matters for anyone using a computer’s random numbers. For a simulation or a game, a good pseudo-random recipe is perfect: fast, well tested, and reproducible when you want it to be. For anything someone might want to predict — a password, an encryption key, a lottery — reproducible is the one thing you cannot afford. Even JavaScript’s everyday Math.random() had to be fixed in 2015 after Chrome’s version turned out to have visible patterns, and its own authors say plainly that the fixed version is still not cryptographically secure.

So modern systems split the job. A cryptographic generator — one built so that seeing its output tells you nothing about the next value — is seeded from physical noise the machine collects as it runs: timing jitter, hardware randomness, the odd lava lamp. The recipe stretches; the noise surprises. Your browser exposes the result as crypto.getRandomValues(), and that is where this site’s numbers begin.

Its inventor knew. John von Neumann, who devised the middle-square method to feed the first computer simulations, told a 1949 symposium: “Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin.” The recipe was never meant to be perfect. It was meant to be fast, on a machine with almost no memory, for simulations where a short loop would be caught by the next test. The surprise is not that the recipe failed. It is how long the question it raised — how can a machine that always does the same thing produce something it couldn’t have predicted? — stayed open.