Engineering · 2026-03-27

QRNG vs. CSPRNG: The Entropy Identity Systems Need

By J. W. Bouckaert

Randomness in identity systems

Every identity system in production depends on randomness. Session tokens, WebAuthn challenges, API keys, nonces, initialization vectors for AES-GCM and salts for password hashing all need bytes an attacker cannot predict. If those bytes become guessable, the security built on them fails.

Few identity vendors say where those bytes come from.

The standard answer is a Cryptographically Secure Pseudo-Random Number Generator, or CSPRNG. On Linux, that means /dev/urandom. In browsers and Deno, it means crypto.getRandomValues(). These generators are seeded from operating system entropy, such as interrupt timing and hardware random number instructions, and stretched through deterministic algorithms like ChaCha20 or an AES-CTR DRBG.

Properly seeded CSPRNGs are sufficient for nearly every application. This article compares them with quantum random number generators (QRNGs), explains what QRNG seeding does and does not add, and describes where PasskeyBridge uses it: the salt for BLAST tunnel key derivation and the nonces in its post-quantum signatures.

Randomness in cryptography

Randomness in cryptography is measurable. NIST SP 800-90B specifies how to estimate the entropy an entropy source produces and how to health-test it continuously. A perfect source produces 8 bits of entropy per byte: every bit independent, uniformly distributed and unpredictable.

CSPRNGs do not produce entropy. They stretch it. A CSPRNG takes a seed of genuine randomness, typically 256 bits, and deterministically generates output that is computationally indistinguishable from true randomness. The security of that output depends on two properties:

1. Seed and state secrecy. If an attacker learns the seed or the internal state, the output that follows is predictable until the next reseed.
2. Algorithm strength. The expansion function must resist state recovery even when an attacker sees part of the output.

Quantum computers and deterministic expansion

The algorithms underpinning CSPRNGs (AES-CTR, ChaCha20, HMAC-DRBG) are symmetric constructions. Grover's algorithm gives a quadratic speedup against them, so a 256-bit key offers about 128-bit security against a quantum adversary. NIST and the NSA consider that adequate, and a quantum computer does not make recovering a properly seeded AES-256 or ChaCha20 generator's state from its output practical.

The practical risk to a CSPRNG is a poor seed or a leaked state.

State compromise

A CSPRNG keeps internal state, such as a key and a counter. An attacker who captures that state through side-channel leakage, VM introspection or memory forensics on a compromised host can predict the output that follows until the next reseed. Poor seeding has also caused real failures, such as the 2008 Debian OpenSSL bug that left only 32,768 possible keys per key type and size.

Frequent reseeding from a source independent of the host limits how long a captured state stays useful, and mixing two independent sources means a weakness in one does not by itself make the seed predictable. That is the case for QRNG seeding. A QRNG-seeded DRBG still has state between reseeds, so QRNG seeding does not remove state compromise as a risk.

Post-quantum migration

The NSA's CNSA 2.0 guidance sets a timeline for national security systems to move to quantum-resistant algorithms: new acquisitions are to be CNSA 2.0 compliant from January 1, 2027, and the transition is to be complete by 2035. CNSA 2.0 concerns algorithms. It does not require quantum entropy sources.

QRNG mechanisms

A QRNG derives randomness from quantum mechanical processes. Three approaches are common:

1. Photon detection

A light source sends photons toward a beam splitter. Whether each photon is transmitted or reflected is random under the Born rule of quantum mechanics, and a pair of single-photon detectors records the outcome as a bit. ID Quantique (Quantis) and Quside build QRNG hardware based on quantum optical processes.

2. Vacuum fluctuation sampling

Quantum field theory predicts energy fluctuations even in a vacuum, and the Casimir effect is one experimental confirmation. Homodyne detection of these fluctuations produces a continuous random signal. Australian National University's QRNG uses this approach and offers a public API.

3. Photonic quantum circuits

Quantum Computing Inc. (QCi) offers a uQRNG platform based on photonic quantum circuits.

In all three, the raw output is a measurement of a physical process rather than the result of an algorithm, so there is no seed or state behind it. Real devices still need post-processing and health testing, because detectors and electronics introduce bias.

QRNG vs. CSPRNG: The comparison

In practice the two are combined: quantum entropy seeds a deterministic DRBG, which supplies the volume of output.

The architecture: Seed and stretch

PasskeyBridge does not call a QRNG API for every byte of randomness it needs. A network call per byte would put provider latency on every request. Instead, its QRNG-DRBG module works like this:

1. Seed. Draw a 256-bit seed from the highest-priority QRNG provider that responds. Each draw is checked with the SP 800-90B continuous health tests, and a draw that fails is rejected and the next provider tried.
2. Mix. XOR the seed with 256 bits from the local CSPRNG, so the result stays unpredictable even if the provider returns degraded output.
3. Key. Import the mixed seed as an AES-256-CTR key through the Web Crypto API.
4. Stretch. Encrypt zero-filled blocks in AES-CTR mode to produce output, incrementing the counter per block.
5. Reseed. After 1,000 requests or 60 seconds, whichever comes first, draw a fresh seed in the background and rekey.

The construction is modeled on the CTR_DRBG in NIST SP 800-90A. It has not been validated against that specification.

The provider hierarchy

PasskeyBridge tries its entropy providers in this order:

If a provider is unavailable or its draw fails the health tests, the module moves to the next one, and the CSPRNG fallback means entropy generation never blocks. Every seed is logged to the shield_entropy_pool table with its source provider, health-test results and the SHA-384 hash of the mixed seed, never the seed itself.

Each source's role in PasskeyBridge

The quantum-seeded DRBG and the runtime CSPRNG each have their own jobs:

QRNG draw XOR local CSPRNG → mixed seed (SHA-384 logged) → AES-CTR DRBG → BLAST salts, signature nonces
Runtime CSPRNG → WebAuthn challenges, AES-GCM IVs, X25519 key pairs

Each hybrid post-quantum signature records the hash of the seed its nonce came from, so a signature can be traced to its seed record and provider.

WebAuthn challenges come from the runtime CSPRNG. A predictable challenge would let an attacker replay a captured assertion, so challenges need unpredictability, and a properly seeded CSPRNG provides it. Initialization vectors also come from the CSPRNG, and what matters for them is that they never repeat: if an IV is reused in an AES-256-GCM BLAST tunnel, Joux's forbidden attack can recover the authentication key.

The compliance angle

Several frameworks treat entropy quality as an auditable control:

• NIST SP 800-90C (Recommendation for Random Bit Generator Constructions) specifies how entropy sources and DRBGs are combined into complete random bit generators.
• Common Criteria network device protection profiles require a documented entropy source and a DRBG seeded with a minimum amount of entropy.
• FIPS 140-3 module validation includes entropy source validation under SP 800-90B.

For enterprises pursuing SOC 2 or FedRAMP, a per-seed record of which source produced the entropy and whether it passed its health tests is evidence an auditor can inspect.

The counterargument

The strongest counterargument is simple: modern CSPRNGs, properly seeded, have not been broken in practice. /dev/urandom on a well-maintained Linux system, seeded from interrupt timing and RDRAND, produces output that passes the NIST SP 800-22 statistical tests, and no published attack recovers a properly seeded CSPRNG's state from its output alone.

That argument is correct, and it holds against quantum adversaries as well. PasskeyBridge's reasons for QRNG seeding are narrower: a second entropy source independent of the host, mixed with the local one; health tests on every draw; and a provenance record for every seed. The cost is a provider call on each reseed, made in the background.

Practical implications for platform engineers

If you are building an identity platform or evaluating one, here are the questions to ask about entropy:

1. What seeds your DRBG? If the answer is "the operating system," follow up: which entropy sources? Are hardware RNG instructions (RDRAND/RDSEED) enabled? Is the pool adequately seeded at boot, including on freshly cloned VMs?

1. How often do you reseed? A DRBG that seeds once at process startup and never reseeds keeps a captured state useful indefinitely.

1. Is entropy provenance auditable? Can you show an auditor which entropy source produced the seed behind a given cryptographic operation?

1. What is your post-quantum migration plan? CNSA 2.0 sets dates for national security systems, and other sectors are following with their own guidance.

1. Do you mix entropy sources? XOR-mixing two independent sources keeps the seed unpredictable as long as either source is sound.

PasskeyBridge's answers: its DRBG is seeded from QRNG providers XOR-mixed with the local CSPRNG. A background reseed starts when the seed is 60 seconds old or has served 1,000 requests, and that seed keeps serving while the refresh runs. When the seed is 5 minutes old or has served 5,000 requests, whichever comes first, the next call waits for a new seed and returns no bytes until that reseed succeeds. Every seed is logged with its provider and health-test results.

Key derivation

PasskeyBridge derives its ML-DSA-65 key pairs deterministically from its at-rest master key with HMAC-SHA-256, rather than generating them from fresh randomness. The master key is a configured secret, not QRNG output, so the strength of those keys rests on how the master key was generated and protected.

Entropy deserves the same scrutiny as algorithms. Knowing which source feeds which operation, and keeping a record of it, is part of running identity infrastructure.

Explore how PasskeyBridge implements post-quantum identity →

Start free · Test the API