Random Number Generator

Why a raffle needs cryptographic randomness

The usual objection to caring about this is that nobody is going to attack a random number generator to win a mug. That is true and it is not the point. The point is what you can say afterwards. A draw made with Math.random cannot be defended against somebody who claims the result was predictable, because it was: the generator's state is recoverable from its outputs, and anybody who saw the previous few numbers had enough to work with.

A draw made from crypto.getRandomValues has no such story. It pulls from the operating system's entropy pool, the same source used to generate encryption keys, and there is no sequence to reconstruct. It costs nothing extra and it removes the argument entirely.

The same reasoning applies to sampling for an audit, allocating participants to groups in a study, or picking which of your customers gets the follow-up call. In all of those the value of the randomness is that it is defensible, not merely that it is varied.

Every number equally likely, which takes some care

Squeezing a random value into a range with a remainder introduces bias whenever the range does not divide the source evenly, and it almost never does. Asking for a number from 1 to 100 out of a 32-bit source leaves a remainder, and the low end of the range comes up fractionally more often. The effect is tiny at that scale and grows as the range gets closer to the source size.

This tool discards values that fall in the uneven tail and draws again, which makes the distribution exactly uniform rather than nearly uniform. The rejection rate for ranges of the size people actually use is under one in two billion, so the cost is nothing.

It is the kind of correctness that is impossible to spot by using the tool and straightforward to verify by measurement, which is how it was checked: a chi-squared test over hundreds of thousands of draws across several range sizes, including the awkward ones like 62 and 95.

Drawing without repeats

Asking for ten unique numbers between 1 and 100 has an obvious implementation: draw a number, check whether you have seen it, draw again if you have. It works, and it degrades badly. Asking for 99 unique numbers out of 100 means the last few draws spend nearly all their time rediscovering numbers already taken, and the expected number of draws grows without bound as the request approaches the size of the range.

Shuffling the whole range and taking the front of it is exact and finishes in a predictable amount of work regardless of how much of the range you want. That is what happens here.

The shuffle itself is Fisher-Yates, walked backwards. The forwards version, where each position is swapped with any other position, is the one people write from memory and it does not produce a uniform permutation: it generates n to the power n equally likely sequences spread over n factorial outcomes, and those do not divide evenly, so some orderings come out more often than others. Going backwards and swapping only with an index at or below the current one is the version that is actually uniform. It was checked by generating a quarter of a million shuffles of four items and confirming all 24 permutations came up in the right proportion.

There is no seed, on purpose

Some generators let you set a seed so the same draw can be reproduced. That is genuinely useful for testing and for reproducible research, and it is exactly wrong for a prize draw, because a reproducible draw is one somebody can claim you ran repeatedly until you liked the answer.

There is no seed here and no way to recover a previous draw. If you need reproducibility, use a seeded generator and publish the seed in advance, which is the only version of that idea that actually establishes anything.