True Random vs Pseudo-Random Numbers

A pseudo-random number generator (PRNG) is an algorithm that produces a long stream of numbers that pass most statistical tests for randomness but are, in fact, fully determined by a starting value called the seed. Give a PRNG the same seed and it replays exactly the same sequence. That is not a bug — it is what makes simulations reproducible and games replayable. Classic examples include the linear congruential generators built into older languages and the Mersenne Twister used in many scientific tools.

The catch is predictability. If someone learns the seed or observes enough outputs, they can reconstruct the internal state and predict every future number. For a dice game that does not matter. For anything protecting money or accounts, it is fatal — which is why the everyday Math.random() found in browsers should never be used for security.

True random number generators do not calculate anything — they measure unpredictable physical phenomena and turn them into bits. Sources include electronic thermal noise, the timing jitter of a chip, atmospheric radio static, and quantum effects like radioactive decay or photons hitting a sensor. Because the underlying process has genuine physical uncertainty, no formula can reproduce the output, even in principle.

In practice, modern operating systems blend the two ideas. They collect entropy from hardware events — key presses, mouse movement, disk timings, a dedicated CPU instruction — and feed it into a cryptographically secure PRNG (a CSPRNG). The result is fast like a PRNG but unpredictable like a true source. This is exactly what the browser's crypto.getRandomValues() exposes — and it is what RandomNest's password and UUID generators use under the hood.

For most everyday tasks — rolling dice, shuffling a playlist, picking a raffle winner among friends — a good PRNG is indistinguishable from true randomness and perfectly fine. Reach for a cryptographically secure source only when an adversary could benefit from guessing the outcome: passwords, session tokens, API keys, encryption material and anything auditable, like a public prize draw.

The good news: RandomNest's password and UUID generators draw from the browser's secure generator, so you get cryptographic-grade randomness whenever it actually matters — you never have to protect an account with a weak formula. For dice, coin flips and casual draws, the everyday generator is fast and perfectly fair.

A modern operating system keeps an entropy pool — a buffer stirred by events nobody can predict: interrupt timings, the microsecond gaps between keystrokes and mouse moves, disk and network latencies, and on most current processors a hardware instruction such as RDRAND that samples thermal noise on the chip itself. Linux hands the result out through /dev/urandom and the getrandom() call, macOS through its own kernel generator, and Windows through BCryptGenRandom.

The pool does not hand out raw noise. It seeds a cryptographically secure pseudo-random generator that is reseeded regularly, so the stream stays fast and uniform while remaining unpredictable even to someone who has already seen megabytes of its output. That is exactly what sits behind crypto.getRandomValues() in every browser, which is why a web page can produce keys and passwords as strong as anything a server would generate.

Two edge cases are worth knowing about. Freshly booted embedded devices sometimes have almost no entropy to work with, which once left thousands of routers sharing identical SSH host keys. And a virtual machine restored from a snapshot starts with the same pool it had when the snapshot was taken, which is why hypervisors reseed their guests on resume.

Turning random bits into a number in a range is less obvious than it looks. Take one byte, which gives you 0 to 255, and ask for a die roll with byte % 6 + 1. Two hundred and fifty-six does not divide evenly by six: four of the faces come up on 43 of the byte values and two come up on 42, so those four faces appear about two per cent more often. Over a handful of rolls nobody notices; over a hundred thousand, the bias is plain.

The standard cure is rejection sampling: find the largest multiple of six that fits, which is 252, discard any byte of 252 or above, and only then take the remainder. You throw away about 1.6 per cent of your draws and get a perfectly uniform die in exchange. The generators here reject out-of-range values rather than folding them in with a bare modulo, which is why the counts in a large batch settle where the theory says they should.