Comparisons

\"100% random draw\": why that promise demonstrates nothing

· · By Yuval Abudarham

A draw your entrants can recompute themselves

Seed published before the draw, public drand randomness, shareable video. Free for entrants.

Create an accountVerify an existing draw

Open any prize-draw tool's page: you'll read "random", "impartial", "fair". Those words are true everywhere, which makes them useless for comparing. The discriminating word is elsewhere.

Unpredictable is not verifiable

Two distinct properties, systematically conflated.

Unpredictable: nobody can guess the result in advance. Every serious generator is, including a spreadsheet's.

Verifiable: anyone can, afterwards, recompute the result and confirm it is the one announced. Almost no tool is.

A draw can be perfectly unpredictable and entirely unverifiable. That is in fact the common case, and precisely the situation that leaves an organizer unprotected: they have nothing to set against a suspicion.

The problem isn't randomness, it's the number of attempts

Here is the reasoning error running through the whole sector. People question the quality of the generator, when the attack never targets it.

A dishonest organizer has no need to rig a random generator. They simply re-run it until a convenient name appears. The generator remains beyond reproach; the result, however, was chosen.

This attack leaves no trace, and no improvement to the generator hinders it. Which is why "we use a cryptographically secure generator" answers a question nobody asked.

What makes the attack impossible

One arrangement closes it, and it has nothing to do with randomness: it has to do with timing.

  1. Before entries open, publish the fingerprint of a secret seed — `sha256(seed)`. The seed cannot be deduced from it; nor can another seed later be produced yielding the same fingerprint.
  2. Announce which randomness will be used: a draw number from a public source, still in the future.
  3. At closing, freeze the entrant list and publish its fingerprint, before that randomness exists.
  4. The randomness appears, publicly, at the scheduled time. The result is computed from those three elements.

From then on, re-running achieves nothing: the three inputs are frozen, and two of them were frozen before the third existed. Exactly one result is possible, and it is the same for everyone.

The reversal

The vocabulary changes meaning. It is no longer the organizer asserting the draw was honest: it is the entrant observing it, with the published values and a verifier they run themselves.

That is the difference between a promise and a demonstration. A promise asks for trust; a demonstration makes it unnecessary.

How to read a product page from now on

Says nothing: "random", "impartial", "fair", "certified algorithm", "secure generator".

Says something: "fingerprint published before entries open", "external public randomness source", "list sealed at closing", "independent verifier", "recomputable result".

The first list describes an intention. The second describes a mechanism. Only the second survives a challenge.

Key takeaways

Every tool is unpredictable and almost none is verifiable. The realistic attack isn't rigging the randomness, it's re-running it until the right result — and it leaves no trace. What makes it impossible isn't a better generator, but commitments published before the randomness exists. "Random" is a promise; "recomputable" is a demonstration.

FAQ

Isn't a certified random number generator enough?

It guarantees the quality of a value, not how many times it was requested. Certification covers the component, the fraud concerns the usage.

Why not simply publish the entrant list?

Because it is personal data, and publishing it would breach the GDPR. The solution is to publish a fingerprint of the list: it proves the list hasn't changed without revealing anyone.

Can the randomness come from the organizer themselves?

Only in part. A secret seed committed in advance is a legitimate contribution, provided it is combined with a public value the organizer doesn't control. On its own, it returns us to the number-of-attempts problem.

How do you explain this to non-technical entrants?

In one sentence: "we published everything needed to compute the draw before it happened, and the randomness used did not yet exist." Few people want the detail; many are reassured that it's available.

Try it