Hardware Random Number Generators vs. Software: Where the Randomness Actually Originates
A hardware random number generator — what NIST’s standards call an entropy source — measures a physical process such as electronic circuit noise, thermal fluctuation, or timing jitter directly, sample by sample. A software cryptographically secure pseudorandom number generator, or CSPRNG, does not manufacture randomness on its own; it takes a comparatively small seed of that same kind of physical entropy, often just 256 bits, and algorithmically expands it into a far larger, still-unpredictable stream of output using a deterministic generation algorithm defined under a standard such as NIST SP 800-90A.
A worked example with numbers
The relationship between the two is not a rivalry so much as a pipeline. Consider what actually happens when a browser calls crypto.getRandomValues(): the call itself runs entirely in software, using a deterministic algorithm, but that algorithm is periodically reseeded from the underlying operating system’s own entropy pool — and on virtually every modern computer or phone, that OS-level pool is itself fed by a dedicated hardware entropy source, such as the RDSEED instruction built into modern CPUs, rather than the old folklore sources like mouse-movement or keystroke timing that older systems once relied on more heavily. In practice, almost every “software” random number call a website makes is hardware-rooted at the seed and algorithmically amplified after that — the honest question is not “hardware or software” as a binary choice, but “how far removed is this specific output from the physical measurement, and how is that gap being bridged.”
How to set the rule before the result
To check which category a specific system actually uses, look at where its documentation places the boundary: a browser or general-purpose programming language’s built-in random API is almost always software — an algorithm seeded and periodically reseeded from the OS — while a dedicated physical device, such as a standalone thermal-noise or quantum-noise hardware RNG sold for applications needing fresh entropy on every single call rather than an algorithmically stretched stream, is a discrete hardware source in its own right. Most everyday uses, including the tools on this site, do not need a dedicated hardware device at all: a correctly seeded and reseeded software CSPRNG, drawing periodically from the OS’s hardware-rooted pool, meets the practical unpredictability requirement without the cost, speed penalty, or added complexity of a standalone physical generator.
Common mistakes that change the odds or the process
A common mistake is assuming “hardware” automatically means “more random” or higher quality than “software”; a properly designed, correctly seeded and reseeded software CSPRNG is, for any practical purpose, indistinguishable from true randomness — the two approaches differ in mechanism, not necessarily in the quality of the final output, and a badly designed algorithm (the failure mode covered in this site’s comparison of legacy linear congruential generators against modern CSPRNGs) is a completely separate problem from the hardware-versus-software question. A second mistake is assuming a dedicated hardware RNG chip needs no ongoing testing once installed; physical entropy sources can and do degrade over a device’s lifetime — a noise diode can drift as it heats or ages — which is exactly why NIST SP 800-90B mandates the continuous Repetition Count and Adaptive Proportion Tests described elsewhere on this site, run specifically against hardware noise sources, not against algorithmic output. A third mistake is assuming a seed and its algorithmically generated output must be the same size, or carry the same kind of randomness; a well-vetted deterministic algorithm can safely expand a modest seed into gigabytes of unpredictable output without needing one freshly measured physical bit for every output bit, which would be far too slow for almost any real application.
Where this method stops being appropriate
This hardware-versus-software distinction describes where entropy is measured versus where it is algorithmically stretched; it says nothing on its own about whether a specific implementation is correct — a hardware source with a manufacturing defect, or a software generator that is improperly or infrequently reseeded, can each fail independently of which category it belongs to. It also does not apply to generators that were never designed to meet either standard’s unpredictability bar in the first place, such as a classic linear congruential generator or a browser’s ordinary Math.random(), both covered elsewhere on this site — those fail for reasons unrelated to whether their entropy happens to come from hardware or software.
How the random source fits into the rule
NIST SP 800-90B documents the physical entropy-source requirements a hardware RNG must meet, including the continuous health tests referenced above; NIST SP 800-90A documents the deterministic algorithm layer a software CSPRNG uses to stretch a seed into a longer output stream; MDN’s Crypto.getRandomValues reference documents the browser API most everyday software randomness on the web ultimately runs through.
Hardware entropy source vs. software deterministic generator
| Hardware entropy source | Software CSPRNG | |
|---|---|---|
| What it measures | A physical process directly | Nothing directly — expands a seed algorithmically |
| Governing standard | NIST SP 800-90B | NIST SP 800-90A |
| Typical output volume | Limited by the physical process’s sampling rate | Effectively unlimited from one seed |
| Typical failure mode | Physical degradation of the noise source | Improper or infrequent reseeding |
Both rows describe legitimate, standards-governed approaches; neither one is simply the “upgraded” version of the other, since they solve different parts of the same overall problem — measuring unpredictability, and then making that unpredictability available at practical speed and volume.
A second case: what a degrading hardware source looks like from the software side
Suppose a hardware noise diode feeding an OS’s entropy pool gradually overheats, and its assessed min-entropy drops from 8 bits per sample to 4 bits per sample without failing outright. Using this site’s earlier Repetition Count Test figures, a source assessed at 8 bits needs only 4 identical consecutive samples to trigger a failure signal, while a degraded 4-bit source needs 6 — meaning the continuous test would still reliably catch this specific kind of gradual degradation, just with a slightly longer run of repeats required before it does, rather than needing a completely different detection mechanism once the source’s quality has already dropped.
Why most “software” randomness is secretly hardware-rooted
The common framing of hardware and software random number generators as two separate, competing universes misses how deeply the two layers actually depend on each other in ordinary use. An operating system’s entropy pool — the reservoir a browser’s software CSPRNG periodically draws fresh seed material from — is itself continuously topped up from hardware-level sources such as a CPU’s built-in noise-sampling instruction. A “purely software” random number, with no hardware entropy anywhere upstream of it, would have to rely entirely on a fixed initial seed and a deterministic formula from that point forward — which is precisely the predictable linear-congruential-generator failure mode covered elsewhere on this site, not a description of how any modern browser or operating system’s random API is actually built.
What a 256-bit seed actually looks like in code
Requesting a seed of exactly 256 bits is not an abstract figure — it corresponds to a concrete, checkable request: filling a 32-byte typed array, since 32 bytes × 8 bits per byte = 256 bits exactly, is the kind of call crypto.getRandomValues() is documented to support directly. A developer can confirm a specific library or API is requesting a seed of that size by checking the byte length of whatever buffer it passes to the underlying cryptographic call, rather than taking a vendor’s “256-bit security” marketing claim on faith; the byte count in the actual API call is a directly verifiable fact, independent of any surrounding documentation or promotional language.