Random Selection Algorithms Explained: What Actually Makes a Picker Fair
Quick Answer
Not all random algorithms are equal. LCGs (Linear Congruential Generators) are predictable from their outputs. The Mersenne Twister looks random statistically but can be broken with 624 observations. Math.random() in your browser is a PRNG — not suitable for high-stakes giveaways. Only a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), seeded with hardware entropy, produces output that is genuinely impossible to predict or manipulate. WheelieNames uses Web Crypto API's crypto.getRandomValues() — a CSPRNG backed by your OS entropy pool.
TL;DR
Most people assume online pickers are truly random, but there is a critical difference between pseudo-random algorithms (which are predictable if you know the seed) and cryptographically secure random generators (which are genuinely unpredictable). This guide explains the three main algorithm families — LCG, Mersenne Twister, and CSPRNG — in plain language, explains why JavaScript's Math.random() is inappropriate for giveaways, describes what entropy means and where it comes from, and shows how experts verify randomness using NIST test suites.
Key Takeaways
- •Linear Congruential Generators (LCGs) are predictable from their output and should never be used for fair selection
- •The Mersenne Twister passes all statistical tests but can be broken by an attacker who observes 624 consecutive outputs
- •Math.random() in JavaScript is a PRNG — it is not suitable for giveaways where fairness can be challenged
- •CSPRNGs gather entropy from hardware events (disk timing, keyboard interrupts) that cannot be predicted externally
- •Fisher-Yates shuffle is fair only when seeded with a CSPRNG — the shuffle algorithm itself is not the source of fairness
Data Window: Research period: 2020-2025 random number generation, cryptographic security, and algorithm verification studies
When you use an online wheel picker or name randomizer, there is a piece of software under the hood generating numbers. Most users never think about what kind of software it is — but they should, because the difference between a pseudo-random algorithm and a cryptographically secure one is the difference between a result that looks random and a result that is genuinely impossible to predict or manipulate. This guide explains the three main algorithm families in plain English, shows you why Math.random() is not appropriate for giveaways, and gives you a clear framework for evaluating whether any tool you use is actually fair.
Table of Contents
- The Fundamentals: What Every RNG Has in Common
- Linear Congruential Generators: Fast but Broken
- Mersenne Twister: Statistically Great, Cryptographically Weak
- Why Your Browser's Math.random() Isn't Random Enough for Giveaways
- CSPRNG: The Gold Standard for Fair Selection
- Entropy: Where True Randomness Actually Comes From
- Fisher-Yates Shuffle: The Selection Step Explained
- Testing Randomness: How Experts Verify True Randomness
- Algorithm Comparison: Which to Use When
- FAQ
The Fundamentals: What Every RNG Has in Common
Every random number generator, regardless of how sophisticated it is, follows the same basic structure: it takes some input (the seed), applies a transformation, and produces output that appears random. The differences between algorithms are all in how they answer three questions:
1. Where does the seed come from?
A seed from the current time in milliseconds is weak. A seed from hardware thermal noise is strong. The quality of randomness output can never exceed the quality of the seed input.
2. Can the seed be guessed from the output?
In a basic PRNG, yes — often with just a few observations. In a CSPRNG, this is computationally infeasible by design.
3. How long before the sequence repeats?
The period of a generator matters: a short period means the same sequence appears repeatedly. For giveaways, period length matters less than unpredictability, but a very short period is an automatic red flag.
Linear Congruential Generators: Fast but Broken for Giveaways
The Linear Congruential Generator is the simplest and oldest pseudo-random algorithm still in common use. Its formula is:
X(n+1) = (a × X(n) + c) mod m
where a, c, m are fixed constants and X(0) is your seed
To make it concrete: suppose a = 1664525, c = 1013904223, and m = 2^32 (common values from Numerical Recipes). If your seed is 42, your first output is (1664525 × 42 + 1013904223) mod 2^32 = some specific number. Then you feed that number back in, and so on. The formula produces a deterministic sequence that looks random but is completely reproducible from the seed.
Here is why this is a problem for giveaways:
- If the seed is the timestamp, an attacker who knows roughly when you ran the selection can try timestamps within a narrow range until they find one that produces your announced winner. This is called a seed brute-force attack.
- From just 2-3 outputs, an attacker can solve for the seed mathematically using lattice reduction techniques, and then predict all future outputs.
- LCGs have structural weaknesses in low-order bits. The sequence of the lowest bit alternates 0, 1, 0, 1... which is not random at all.
Bottom line: Never use an LCG-based tool for any giveaway where someone has a financial incentive to cheat. The security is not theoretical — it is trivially breakable in practice.
Mersenne Twister: Statistically Great, Cryptographically Weak
The Mersenne Twister (MT19937) is what most modern programming languages use as their default random number generator. Python's random module, Ruby's rand, R's default RNG — they all use variants of the Mersenne Twister. It was designed in 1997 specifically to address the weaknesses of LCGs.
The Mersenne Twister's strengths are impressive:
- Period of 2^19937 - 1 — the sequence would not repeat for a number of steps that dwarfs the number of atoms in the observable universe
- 623-dimensionally equidistributed — extremely uniform distribution across high-dimensional spaces
- Passes all standard statistical tests — including NIST SP 800-22, Diehard, and TestU01
- Very fast — several times faster than cryptographic alternatives
Here is the catch: the Mersenne Twister maintains an internal state of 624 32-bit integers (19937 bits total). Once an attacker has observed 624 consecutive outputs from the generator — which would happen naturally if your tool generates many random numbers per use — they can reconstruct the entire internal state. From that point, every future output is predictable with certainty.
This makes the Mersenne Twister inappropriate for any application where an adversary might observe enough output to reconstruct the state. For a giveaway tool used by many people who can see previous selection results, this is a real concern. The Mersenne Twister was designed for statistical simulations and games — not for security-critical applications.
Why Your Browser's Math.random() Isn't Random Enough for Giveaways
When a web developer reaches for Math.random() to build a giveaway picker, they are making a common but important mistake. Math.random() in modern browsers (Chrome V8, Firefox SpiderMonkey, Safari JavaScriptCore) typically uses xorshift128+ or a related algorithm. These are fast, have good statistical properties, and produce outputs that look random for casual purposes.
But here is what the JavaScript specification says: Math.random() is explicitly not required to produce cryptographically secure values. In practice, its seed comes from a quick OS call that typically provides far less entropy than a proper CSPRNG seed. And in some environments — particularly server-side JavaScript in early implementations — the seed has been as simple as the startup timestamp, making it predictable.
| Property | Math.random() | crypto.getRandomValues() |
|---|---|---|
| Algorithm family | PRNG (xorshift128+) | CSPRNG (OS kernel) |
| Entropy source | Simple OS seed, low entropy | Hardware events, high entropy pool |
| Cryptographically secure? | No | Yes |
| Suitable for giveaways? | No | Yes |
| Performance | Very fast | Slightly slower but negligible for giveaways |
The correct approach in a browser is to use window.crypto.getRandomValues(), which calls the browser's CSPRNG and is backed by the operating system entropy pool. In Node.js, the equivalent is require('crypto').randomBytes(). These functions are available in all modern environments and have negligible performance overhead for the scale of a typical giveaway.
CSPRNG: The Gold Standard for Fair Selection
A Cryptographically Secure Pseudo-Random Number Generator has two properties that ordinary PRNGs lack:
Next-bit unpredictability
Given all previous outputs, an attacker cannot predict the next bit with probability better than 50% — no matter how much computing power they use. This is the fundamental security property.
Backtracking resistance
Even if an attacker discovers the current internal state, they cannot reconstruct past states. This means past selections remain secure even if the current state is somehow compromised.
The NIST SP 800-90A standard specifies three approved CSPRNG algorithms. Here is what each one does in plain language:
| Algorithm | Core Operation | Best For |
|---|---|---|
| Hash_DRBG | SHA-256 hashing in chain | Simple, widely implemented |
| HMAC_DRBG | HMAC-SHA-256 authentication codes | Stronger security proofs |
| CTR_DRBG | AES encryption in counter mode | Fastest on AES-accelerated hardware |
Entropy: Where True Randomness Actually Comes From
Entropy, in this context, means unpredictability. High-entropy data is data that cannot be predicted — it contains genuine randomness from the physical world. Low-entropy data has patterns or comes from predictable sources.
Your computer's operating system maintains an entropy pool — a reservoir of unpredictable bits collected from dozens of hardware sources:
Disk drive timing
The precise nanosecond timing of disk read/write operations varies due to mechanical and electromagnetic variation
Keyboard interrupt timing
The exact CPU cycle when your keypress is registered is unpredictable at nanosecond precision
Network packet timing
Internet packet arrival times include network jitter that is genuinely random
Hardware thermal noise
Modern CPUs have dedicated hardware random number generators (HRNG) that measure thermal noise
Mouse movement
The exact pixel coordinates and timing of mouse movements are environmentally unpredictable
CPU performance counters
Instruction timing varies based on cache states, branch prediction, and thermal effects
On Linux, this pool is accessible via /dev/urandom (and /dev/random for blocking reads). On Windows, the BCryptGenRandom API serves the same function. On macOS and iOS, /dev/urandom uses the Fortuna CSPRNG seeded by the kernel entropy pool. When you call crypto.getRandomValues() in a browser or crypto.randomBytes() in Node.js, you are drawing from this pool.
Fisher-Yates Shuffle: The Selection Step Explained
When you have 500 participants and need to pick 1 winner, the selection typically works in two steps: generate a random number, then use it to pick a participant from the list. The standard algorithm for doing this fairly is called the Fisher-Yates shuffle (also known as the Knuth shuffle).
Think of it this way: if you want to pick one item from a list of N items with equal probability, you need a random integer between 0 and N-1 where every value is equally likely. That integer directly indexes your participant list. The key insight is that Fisher-Yates guarantees this equal probability only if the random number generator feeding it is uniform and unbiased.
A common mistake is using modulo arithmetic with a PRNG: Math.floor(Math.random() * N). When N does not evenly divide the PRNG's output range, this introduces modulo bias — some participants have a very slightly higher probability of selection than others. This bias is tiny in practice but violates the strict equal-probability guarantee. A proper implementation uses rejection sampling to eliminate this bias.
Testing Randomness: How Experts Verify True Randomness
How do experts determine whether a generator is truly random? They use statistical test batteries — thousands of tests designed to catch specific patterns that indicate a non-random generator.
NIST SP 800-22 Test Suite
The standard battery for cryptographic RNG evaluation. Includes 15 tests: frequency (monobit) test, block frequency test, runs test, longest run test, binary matrix rank test, spectral test, overlapping patterns, universal statistical, linear complexity, serial, approximate entropy, cumulative sums, random excursions, and random excursions variant tests. A proper CSPRNG must pass all of them.
TestU01 BigCrush
The most rigorous available statistical test suite, developed at the University of Montreal. It runs 106 different tests and requires billions of random numbers to complete. The Mersenne Twister passes all NIST tests but fails some BigCrush tests, illustrating how statistical testing alone is insufficient to certify cryptographic security.
Why Passing Tests Is Not Enough
Statistical tests verify that the output is uniformly distributed and lacks obvious patterns. They do not verify that the generator is unpredictable from an adversarial standpoint. A generator can pass all statistical tests and still be completely predictable once an attacker knows the algorithm and has seen enough output. Cryptographic security requires formal proof from cryptographic theory, not just empirical testing.
Algorithm Comparison: Which to Use When
| Algorithm | Predictable? | Passes Stats Tests? | Safe for Giveaways? | Best Use Case |
|---|---|---|---|---|
| LCG | Yes — easily | Partially | No | Simple embedded systems |
| Mersenne Twister | Yes, after 624 outputs | Yes | No | Simulations, games |
| Math.random() | Potentially yes | Yes | No | Casual web features, animations |
| CSPRNG (NIST-approved) | Computationally infeasible | Yes | Yes | Giveaways, cryptography, security |
The practical takeaway for you as a giveaway organizer: ask the tool you use whether it relies on Math.random() or a CSPRNG. If the documentation does not mention this, email the developer. A legitimate tool with cryptographic randomness will be transparent about it because it is a feature worth promoting.
Next step: Once you understand how fair randomization works, the next question is how to verify it after the fact. Read our complete guide to verifying random selection fairness for a step-by-step audit process.
Frequently Asked Questions
How do random selection algorithms actually work?
Every random selection algorithm starts with a seed — a starting value — and applies a mathematical transformation to produce a sequence of numbers. The key difference between algorithm types is where the seed comes from and whether the sequence is predictable. Simple pseudo-random algorithms like Linear Congruential Generators use a formula like: next = (a × current + c) mod m. This is fast and produces numbers that look random, but anyone who knows the seed and the formula can compute every future number in the sequence. Cryptographically secure algorithms (CSPRNGs) gather their seed from genuinely unpredictable physical sources — hardware timing events, thermal noise, OS kernel entropy — making prediction computationally infeasible even with full knowledge of the algorithm.
What is the difference between pseudo-random and cryptographically secure random?
Pseudo-random number generators (PRNGs) are deterministic: given the same starting seed, they always produce the same sequence. This is actually useful for reproducibility in simulations and games, but it is a fatal flaw for giveaways — if the seed is predictable (like a timestamp), someone can calculate the winner before you announce it. Cryptographically secure pseudo-random number generators (CSPRNGs) use the same mathematical structure, but their seeds come from genuinely unpredictable physical sources. The key cryptographic property is backtracking resistance: even if you can see the current CSPRNG output, you cannot work backward to discover the seed. This makes the sequence truly unpredictable from outside the system.
Why is Math.random() in JavaScript not suitable for giveaways?
JavaScript's Math.random() uses a pseudo-random algorithm internally (typically xorshift128+ or a variant of it, depending on the browser engine). Its seed is usually derived from the current time in milliseconds or from a simple OS call. The result is fast and uniformly distributed for casual use, but it lacks the key property required for fair selection: cryptographic security. A sophisticated attacker who observes enough Math.random() outputs can potentially reverse-engineer the internal state and predict future values. For giveaways where someone might be motivated to cheat, you need the Web Crypto API's crypto.getRandomValues() instead, which calls the OS CSPRNG directly. For node.js server-side code, use the crypto module rather than Math.random().
What is a Linear Congruential Generator (LCG) and what is wrong with it?
A Linear Congruential Generator uses the formula: X(n+1) = (a × X(n) + c) mod m, where a, c, and m are fixed constants and X(0) is your seed. It is extremely fast and simple to implement, which is why it appears in many old programming languages and early random number libraries. The problem for giveaways is threefold: (1) LCGs are entirely predictable if you know the seed, (2) with enough outputs you can reconstruct the seed from scratch using lattice reduction attacks, and (3) LCGs have structural weaknesses in certain bits. The lower bits of LCG output follow extremely predictable patterns. Modern tools should never use LCGs for anything where fairness can be challenged.
What is the Mersenne Twister and is it good enough for giveaways?
The Mersenne Twister (MT19937) is a widely used pseudo-random number generator developed in 1997. It has excellent statistical properties, an enormous period of 2^19937 - 1 (meaning it would not repeat for an astronomically long time), and passes virtually all standard statistical randomness tests. Python's random module and many other language standard libraries use it. However, it is still not suitable for giveaways where fairness can be challenged. The key problem: once you observe 624 consecutive outputs from the Mersenne Twister, you can reconstruct its entire internal state and predict all future outputs. This means a determined participant could potentially predict your winner if they can observe enough of the tool's previous outputs. For giveaways, you need a CSPRNG.
What algorithms do NIST-approved CSPRNGs use?
NIST SP 800-90A specifies three approved Deterministic Random Bit Generators (DRBGs): Hash_DRBG uses iterative SHA-256 hashing to produce output — it is simple, well-understood, and widely deployed. HMAC_DRBG uses HMAC (Hash-based Message Authentication Code) operations, which provides stronger security proofs than plain hashing. CTR_DRBG uses AES encryption in counter mode, which is often the fastest option on hardware with AES acceleration. All three require initialization with entropy from a trusted source (the OS CSPRNG) and provide backtracking resistance — meaning observing current output cannot reveal past or future output. These are the gold standard algorithms for any application requiring verifiable randomness.
How do experts test whether a random number generator is truly random?
Experts use statistical test suites designed to catch specific patterns that indicate a non-random generator. NIST SP 800-22 is the standard battery of tests, including: frequency tests (checking that 0s and 1s appear equally often), runs tests (checking that sequences of same-bit values have expected lengths), block tests (checking patterns in fixed-length blocks), and spectral tests (looking for regularities in the frequency domain). The Diehard battery and TestU01's BigCrush are even more rigorous. Importantly, passing statistical tests is necessary but not sufficient for a CSPRNG: the Mersenne Twister passes all of these tests but is still not cryptographically secure. A CSPRNG must additionally resist computational attacks, which requires proof from cryptographic theory, not just statistics.
What is entropy and why does it matter for random selection?
Entropy, in the information theory sense, measures unpredictability. A byte of high-entropy data contains genuine randomness — it cannot be predicted better than chance. A byte of low-entropy data contains patterns or predictability that reduce its randomness. When a CSPRNG is seeded, the quality of its output depends entirely on the quality of the entropy used to seed it. Operating systems collect entropy from dozens of hardware sources: the precise sub-millisecond timing of disk reads, keystrokes, network packets, and hardware interrupts. These physical events are unpredictable even to a very powerful attacker who can observe the system. The OS pools this entropy in a reservoir (Linux: /dev/urandom, Windows: BCryptGenRandom) and uses it to seed the system CSPRNG, which then generates secure random numbers for applications.
Can a random selection algorithm be verified after the fact?
Yes, with the right tool design. If a selection tool is built so that it records its seed, the algorithm used, and the full participant list, then anyone can re-run the same computation and verify they get the same winner. This is called deterministic verification. The selection was cryptographically random at the time (because the seed came from a CSPRNG), but it is now reproducible given those inputs. This is exactly how provably fair gambling systems work: the seed is committed to before the game (using a hash), revealed after, and anyone can verify the result. For giveaways, a tool that supports seed export lets participants independently confirm the result without having to trust the organizer.
What does Fisher-Yates shuffle have to do with random selection?
When you have a list of participants and need to select a winner, the actual selection step typically uses the Fisher-Yates algorithm (also called Knuth shuffle). Fisher-Yates works by iterating through the list backward: for each position, pick a random index at or before it, and swap the elements. Done correctly, this produces a perfectly uniform random permutation — every ordering of the list is equally likely. The key dependency: Fisher-Yates is only as random as the underlying random number generator you use to pick each swap index. If you use Math.random() for the swaps, the shuffle inherits all of Math.random()'s weaknesses. If you use a CSPRNG, the shuffle is cryptographically fair.
How does WheelieNames approach randomness?
WheelieNames uses CSPRNG-based random number generation rather than browser Math.random(). The Web Crypto API's crypto.getRandomValues() function calls the browser's CSPRNG, which is seeded by the operating system's entropy pool. This means each spin draws randomness from genuinely unpredictable hardware-level sources. The selection uses Fisher-Yates shuffling seeded with this cryptographic entropy, ensuring each participant has a genuinely equal probability of selection that cannot be predicted in advance or reproduced without access to the original entropy.
Conclusion: The Algorithm Matters More Than You Think
Most giveaway participants never think about what random number generator their tool uses. But if you run a high-value giveaway, someone with the right technical knowledge could exploit a weak algorithm. And even setting aside malicious intent, using the right algorithm is simply the honest thing to do — if you claim the selection was random and fair, your implementation should match that claim.
The good news is that using a CSPRNG is not technically difficult. Modern browsers and server environments expose CSPRNG APIs directly. The challenge is knowing to ask for it, and choosing tools that implement it correctly. After reading this guide, you now know what questions to ask and what answers to look for.
Use WheelieNames for your random selection needs — it is built on Web Crypto API's CSPRNG and designed to give you the verifiable fairness that participants expect from a transparent giveaway process.
Related Articles
Share This Article
Help spread the word and share with your network
Preview:Random Selection Algorithms Explained: What Actually Makes a Picker Fair LCG, Mersenne Twister, CSPRNG — which actually matters for giveaways? Learn ...