Random Generator

Why Math.random is not used here

JavaScript's Math.random is specified only as "an implementation-dependent algorithm or strategy" producing values with approximately uniform distribution. It is explicitly not required to be unpredictable, and in practice engines implement it with a fast non-cryptographic generator whose internal state can be recovered from a modest number of observed outputs. For a loading animation that is entirely fine. For anything anyone might treat as fair or secret — a prize draw, a token, a password, a shuffled deck in a game with stakes — it is the wrong tool, and the failure is silent: the numbers look random right up until someone predicts them. crypto.getRandomValues is seeded by the operating system's entropy pool and is designed to resist exactly that, which is why every mode here draws from it.

Uniformity and the modulo trap

Getting a random number in a range is where most implementations quietly go wrong. The natural approach — take a random value and use the remainder after dividing by the range — produces a subtly uneven distribution whenever the range does not divide the generator's output space evenly, because the leftover values at the top map back onto the bottom of the range. With a 256-value byte and a range of ten, the first six numbers come up about 17% more often than the last four. Rejection sampling avoids it completely: draw, and if the value lands in the incomplete final block, throw it away and draw again. The cost is an occasional extra draw; the benefit is a distribution that is exactly uniform rather than merely close, which is what "fair" has to mean for a draw.