Every programming language ships with a random number generator. Python has random. JavaScript has Math.random(). C has rand(). They all share a fundamental property: they're not random. They're pseudo-random - deterministic algorithms that produce sequences which pass casual inspection but are entirely predictable to anyone who knows the internal state.
How PRNGs Work
A pseudo-random number generator starts with a seed - an initial value that determines the entire output sequence. Given the same seed, a PRNG produces the exact same sequence every time. This is by design: reproducibility is useful for testing, simulation, and debugging.
The algorithm transforms the seed through a mathematical function to produce the next value, which also becomes the new internal state. Common algorithms include the Mersenne Twister (used by Python's random module), Linear Congruential Generators, and the xoshiro family.
The output looks random. It passes many statistical tests. But it carries a critical weakness: the entire sequence is determined by the seed. If you can recover the seed - or observe enough consecutive outputs - you can predict every future value.
When PRNGs Fail
The Mersenne Twister Problem
Python's default PRNG, the Mersenne Twister (MT19937), has an internal state of 624 32-bit integers. After observing just 624 consecutive outputs, an attacker can reconstruct the complete internal state and predict every subsequent value. Tools to do this are freely available.
This makes the Mersenne Twister completely unsuitable for any security-sensitive application. Yet it remains the default random implementation in Python, Ruby, PHP, and many other languages.
The Dual_EC_DRBG Scandal
In 2013, documents leaked by Edward Snowden revealed that the NSA had deliberately weakened the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG), a PRNG standardised by NIST. The algorithm contained a backdoor that allowed anyone who knew a secret constant to predict the output. NIST had standardised and recommended it, and RSA Security had made it the default in their BSAFE toolkit.
The lesson was stark: even cryptographic PRNGs can be compromised if the underlying algorithm is manipulable. The security of a PRNG ultimately depends on trust in its design - and that trust has been broken before.
CSPRNGs: Better, But Still Deterministic
Cryptographically secure PRNGs (CSPRNGs) like /dev/urandom, CryptGenRandom, and random_bytes() are significantly stronger than general-purpose PRNGs. They gather entropy from hardware events (keyboard timings, disk I/O, network interrupts) and use it to seed cryptographic algorithms.
CSPRNGs are appropriate for most cryptographic applications. But they have limitations:
- Entropy starvation - On headless servers with no user interaction, hardware entropy sources may be sparse
- Boot-time vulnerability - Systems are most vulnerable immediately after boot, when the entropy pool is nearly empty
- Deterministic core - Once seeded, the expansion algorithm is still deterministic; the randomness of the output is bounded by the quality of the seed
- Unverifiable - You cannot independently verify that a CSPRNG's output is truly random; you trust the implementation
Enter Quantum Randomness
Quantum random number generation sidesteps these problems entirely. The randomness doesn't come from an algorithm - it comes from physics.
When a qubit is placed in superposition using a Hadamard gate, it exists in an equal combination of |0⟩ and |1⟩. This isn't a metaphor or an approximation - the qubit is genuinely in both states simultaneously. When measured, it collapses to 0 or 1 with exactly 50% probability each. This outcome is not determined by any hidden variable or prior state. It is fundamentally, provably random.
This is what TrueEntropy uses. Our QuBitLang QRNG circuit applies Hadamard gates to 8 qubits, measures them, and produces 8 truly random bits per execution. With 4,096 shots per circuit execution on IBM Quantum hardware, each job yields 4 KB of quantum entropy.
PRNG vs TRNG: When Does It Matter?
PRNGs are fine for:
- Game development (non-gambling)
- Statistical simulations where reproducibility is desired
- Testing and development
- UI randomisation (animation delays, shuffle effects)
True random numbers are essential for:
- Cryptographic key generation - The security of AES, RSA, and elliptic curve keys depends entirely on the unpredictability of the key material
- Regulated gambling - UKGC and other regulators require independently testable RNG systems
- Clinical trial randomisation - Patient assignment must be unbiased and unpredictable to maintain trial integrity
- Blockchain and NFT provenance - On-chain randomness must be verifiable and free from miner manipulation
- High-stakes financial applications - Monte Carlo simulations, portfolio shuffling, and risk modelling benefit from non-deterministic entropy
The TrueEntropy Approach
TrueEntropy bridges the gap between quantum physics and practical software engineering. You don't need to understand quantum mechanics, operate quantum hardware, or change your application architecture. You make an API call and receive genuinely random numbers - sourced from IBM Quantum hardware, verified by NIST SP 800-22 statistical tests, and delivered from a pre-generated entropy pool.
Your application gets true randomness. Your compliance team gets verifiable provenance. Your users get fairness they can trust. And you get an API that's as simple as the PRNG you're replacing - just better in every way that matters.