"Random number generator" covers at least five quite different things. They are not ranked on a single scale from bad to good — each answers a different question and fails in a different way. This guide compares them on what actually matters: what an attacker would have to know to predict the output, and what it costs to integrate and evaluate the design.
1. Software pseudo-random generators
What they do. Stretch a seed value into a long stream using a formula.
Predictability. Complete, if the seed is known. Some older library functions are worse still: their internal state is small enough to search exhaustively.
Where they belong. Simulations, procedural graphics, load testing, shuffling in non-adversarial settings — anywhere reproducibility is a feature.
Where they hurt. Anywhere the output becomes a secret. Real incidents repeatedly trace back to a library function that looked random enough and was never intended for cryptography.
2. Operating-system randomness
What they do. Collect unpredictable system events, mix them into a pool, and
serve a cryptographically secure stream from it (/dev/urandom,
getrandom(), BCryptGenRandom, the Web Crypto API).
Predictability. Good on a general-purpose machine that has been running for a while, and the correct default for application software.
Where they struggle. Freshly booted devices with no user input, virtual machines cloned from an identical image, and embedded systems that must produce a key within milliseconds of power-on. The pool is only as unpredictable as the events feeding it — and a fallback to a hardware generator that is not actually being called is a failure mode that has happened in shipped firmware.
3. Classical hardware random generators (TRNGs)
What they do. Measure a physical process on a chip — thermal noise in a resistor, jitter between ring oscillators, avalanche noise in a diode — and turn it into bits.
Predictability. No seed to steal. But the unpredictability rests on physical behaviour that can, in principle, be influenced: temperature, supply voltage, clock injection and ageing all shift the statistics, and some of these are within reach of an attacker with physical access.
Where they belong. Practically everywhere already. Most modern microcontrollers and CPUs contain one. The question is rarely "is there a TRNG" and usually "how well characterised and monitored is it".
4. Photonic (optical) QRNG
What they do. Measure a quantum optical process — single-photon paths, vacuum-state fluctuations, laser phase noise — with optical components and detectors.
Predictability. Grounded in quantum behaviour, and the approach with the longest track record and the strongest published theory. Several products are certified.
Trade-offs. Discrete optical parts, alignment, and detectors mean a larger module, higher cost per unit, and integration at board or appliance level rather than inside another chip. That is a fine fit for HSMs, servers and network appliances, and a poor fit for a sensor that costs a few euros.
5. CMOS-native QRNG
What they do. Measure quantum-scale charge behaviour using structures built in the same standard CMOS process as ordinary digital chips.
Predictability. Also grounded in quantum behaviour, with the same obligations as any other design: a documented entropy model, health tests, conditioning and independent evaluation.
Trade-offs. No exotic materials or optics, so the block can be manufactured alongside regular logic and integrated into a larger chip. This is the newest of the five categories, which means fewer certified products on the market and more weight on evaluation evidence. It is the approach iQrypto works on, and the reason this site exists.
Reading the comparison honestly
Two questions cut through most vendor material:
What would an attacker need? For a PRNG: the seed. For OS randomness: the state of the entropy pool at a specific moment. For a TRNG: enough influence over the physical environment to bias the source. For a QRNG: something physics does not offer, provided the measurement is genuine and monitored.
What evidence exists? For every hardware category the answer is the same shape — an entropy model, health tests, conditioning, and evaluation against NIST SP 800-90B or BSI AIS 31 by someone other than the vendor. A category label is not evidence; a report is.
Practical guidance
- Application code should call the operating system's cryptographic API, not a library's convenience random function, and never a bare pseudo-random one.
- Device and platform builders should ask where the first key of a device's life comes from, and what happens when the entropy source degrades in the field.
- Buyers comparing QRNG products should compare evaluation evidence and integration fit, not the word "quantum".
Continue with different approaches to quantum entropy for a closer look at categories 4 and 5.