In August 2026, five crypto wallet apps shipped with the same flaw. Nobody hacked their servers. Nobody cracked their encryption. The apps simply asked a weak random number generator for secrets, and the generator handed back numbers that were far easier to guess than they looked.
That is the whole drama of randomness in software. It sits underneath everything, it is almost invisible, and when it fails the damage is total.
This guide walks through what a random number generator (RNG) actually is, why most of them are not random at all, and where the quality of randomness decides whether a product is trustworthy. You do not need a maths degree. You need to know which questions to ask.
The Dirty Secret: Your Computer Cannot Be Random
A processor follows instructions. Give it the same inputs and it produces the same outputs, every time. Determinism is the entire point of a computer, and it is also the enemy of randomness.
So most software uses a pseudo-random number generator, or PRNG. It starts from a number called a seed, runs it through a mathematical formula, and produces a long stream of values that look random. Feed in the same seed and you get the same stream. Always.
That sounds like a flaw, but it is useful. Game developers reuse seeds to replay a bug exactly as it happened. Scientists reuse them to reproduce a simulation. The old Linear Congruential Generator, a simple multiply-and-add formula, powered a surprising amount of classic software, and classic games leaned on lookup tables and similar tricks to fake unpredictability cheaply.
The weakness is obvious once you say it out loud. If an attacker learns the seed, or can guess it, the whole stream is theirs.
True Randomness Needs Physics
True random number generators, or TRNGs, skip the formula. They measure something in the physical world that nobody can predict: thermal noise in a circuit, timing jitter between keystrokes, or the behaviour of a photon.
The cutting edge is quantum. In 2025 a team at the US standards agency built a service that draws randomness from quantum entanglement, with the aim of producing numbers whose unpredictability can be certified rather than merely assumed. Entangled photons and Bell tests sound exotic, yet Popular Science has covered how the same idea reaches ordinary readers through free public randomness tools.
Most real products do not choose one or the other. They blend them. A hardware source gathers entropy (the raw unpredictability), and that entropy seeds a cryptographically secure PRNG that can then produce numbers quickly and at scale. Your operating system does this constantly in the background. Linux calls it the entropy pool.
Short version: physics supplies the surprise, maths supplies the speed.
When Weak Randomness Breaks Real Products
Here is where the theory gets expensive.
A password manager generates a 20-character password. The strength of that password depends entirely on the generator behind it. If the generator only has, say, a few billion possible starting states, the password is not 20 characters strong. It is a few billion guesses strong, which a modern GPU rig chews through in hours.
The wallet incident is the textbook case. A weak RNG inside a popular JavaScript library squeezed keys that should have had 128 or 256 bits of entropy into a range attackers could search, and millions in funds drained from users who had done nothing wrong. The key length on the label was fine. The randomness feeding it was not.
The pattern repeats across software:
- Session tokens that follow a guessable sequence let someone hijack a login.
- Two-factor codes generated from a predictable source stop being a second factor.
- Shuffled playlists and A/B test splits that are not uniform quietly bias your data.
- Games that reuse a seed let players predict loot drops or enemy behaviour.
I have seen developers reach for `Math.random()` to generate an API key because it was right there. It works. It is also not designed for secrets, and the documentation says so. Convenience beats caution until the incident report arrives.
How Fair Randomness Gets Audited
Here is the awkward problem. You cannot look at a number and tell whether it is random. The sequence 7, 3, 9, 1 could come from a perfect generator or a broken one. Randomness is a property of the process, not of any single output.
So auditors test the process statistically. An independent lab takes millions or billions of outputs from a generator and runs them through batteries of tests. NIST publishes a well-known suite, and the Dieharder and TestU01 collections do similar work. The tests look for bias, repeating patterns, correlations between consecutive values, and distributions that drift from uniform. A generator has to survive all of them, not most of them.
Then comes the second layer: source code review, seeding review, and checks that the implementation in the shipped product matches the one that was tested. A flawless algorithm bolted in wrongly is still a broken product.
Consumer products where fairness is the whole selling point show this machinery most clearly, and digital wheels are the cleanest everyday case. A roulette wheel has 37 or 38 pockets and each should land with identical probability. When a certified generator drives the outcome, labs verify that over enormous sample sizes every pocket comes up at its expected rate. That scrutiny is why roulettes open for Australian bettors are a handy real-world benchmark: the maths is simple enough for anyone to check, and the stakes are high enough that independent testing is the norm rather than the exception.
The lesson travels well beyond wheels. Any product that promises fairness, from loot boxes to raffle apps, should be able to say who tested its generator and how.
Seeding: The Step Everyone Forgets
A brilliant algorithm with a lazy seed is a locked door with the key under the mat.
The classic mistake is seeding from the clock. Use the current time in seconds and an attacker only has to try a few thousand plausible timestamps. People have broken real systems this way, and it keeps happening because the code looks fine on review. The generator is good. The input is guessable.
Good seeding mixes multiple sources: hardware entropy, high-resolution timing, process and device identifiers, sometimes network noise. Modern operating systems expose this through calls such as `getrandom()` on Linux or `BCryptGenRandom` on Windows, and developers should call those instead of rolling their own.
One rule of thumb helps. If you are generating something an adversary would profit from guessing, use the platform’s cryptographic generator. If you are generating something purely cosmetic, like a confetti animation, the cheap one is fine. Matching the tool to the stakes is most of the skill.
What This Means If You Build or Buy Software
If you write code, the checklist is short. Use your language’s cryptographically secure generator for anything secret. Never seed from the clock. Test statistical uniformity if your product depends on fairness, and log seeds in development so bugs stay reproducible.
If you buy or use software, the questions are just as short. Does the vendor say which generator it uses? Has anyone independent tested it? Is the company willing to describe its seeding at a high level?
Vague answers are an answer. A team that understands its randomness can usually explain it in two sentences.
FAQ
What is the difference between a PRNG and a TRNG?
A PRNG uses a mathematical formula and a starting seed to produce numbers that look random but are fully repeatable. A TRNG measures unpredictable physical events, such as electrical noise or quantum behaviour. Most secure systems combine both: hardware entropy seeds a fast, cryptographically secure PRNG.
Is Math.random() safe for passwords or API keys?
No. Math.random() is built for convenience, such as animations or casual shuffling, and it is not designed to resist prediction. For passwords, tokens or keys, use your platform’s cryptographic generator, such as crypto.getRandomValues() in browsers or the operating system’s secure random call.
How can anyone prove a generator is random?
They cannot prove it from a single output. Labs run statistical test suites over billions of values, checking for bias, patterns and correlations, and they review the code and seeding as well. Passing proves the generator behaves randomly under test, which is the strongest practical evidence available.
Why does the seed matter so much?
A seed determines the entire sequence a PRNG produces. If the seed is guessable, such as the current time in seconds, an attacker can rebuild every output. Strong seeds combine several unpredictable sources, so the starting point has far too many possibilities to search.
The Takeaway
Randomness looks like a footnote in software documentation. It is actually a foundation, and foundations only get attention when they crack. Pseudo-random generators are fine for games and simulations. Anything protecting money, identity or fairness needs hardware entropy, a cryptographic generator and independent testing. Ask how the randomness works, and treat a blank stare as useful information.