Engineering · 2026-03-27

QRNG vs. CSPRNG: The Entropy Identity Systems Need

By J. W. Bouckaert

The entropy problem nobody talks about

Every identity system in production today depends on randomness. Session tokens, WebAuthn challenges, API key generation, nonce creation, initialization vectors for AES-GCM, salt values for password hashing—all of them require bytes that an attacker cannot predict. The entire security model of modern authentication collapses the moment those bytes become guessable.

And yet, almost nobody in the identity industry talks about where those bytes come from.

The standard answer is a Cryptographically Secure Pseudo-Random Number Generator—a CSPRNG. On Linux, that means /dev/urandom. In browsers and Deno runtimes, it means crypto.getRandomValues(). These generators are seeded from operating system entropy pools—interrupt timings, disk I/O jitter, thermal noise from CPU temperature sensors—and stretched through deterministic algorithms like ChaCha20 or AES-CTR-DRBG.

CSPRNGs are good. For most applications, they are sufficient. But "sufficient" and "optimal" are not synonyms, and for identity-critical operations—key generation for post-quantum signatures, entropy seeding for BLAST tunnel establishment, nonce generation for A2A trust negotiations—the distinction matters.

This article explains why.

Randomness in cryptography

Randomness in cryptography is a measurable property with precise mathematical definitions. NIST SP 800-90B defines entropy as "a measure of the amount of uncertainty that an entropy source produces." A perfect entropy source produces 8 bits of entropy per byte—every bit is independent, uniformly distributed, and unpredictable.

CSPRNGs do not produce entropy. They stretch entropy. A CSPRNG takes a small seed of genuine randomness—typically 256 bits—and deterministically generates a stream of pseudo-random output that is computationally indistinguishable from true randomness. The security of the entire output stream depends on exactly two properties:

1. Seed secrecy—if an attacker learns the seed, every output byte is predictable.
2. Algorithm resistance—the deterministic expansion function must resist state recovery even given partial output observation.

Both properties hold under classical computational assumptions. The operative word is classical.

The quantum threat to deterministic expansion

The algorithms underpinning CSPRNGs—AES-CTR, ChaCha20, HMAC-DRBG—are symmetric constructions. Grover's algorithm provides a quadratic speedup against symmetric ciphers, effectively halving key strength. A 256-bit AES key offers 128-bit security against a quantum adversary. This is still considered adequate for the near term.

But the threat model has more in it than key-length arithmetic.

State recovery attacks

A CSPRNG maintains internal state—a key and a counter, or a chaining value and a nonce. If an adversary captures a snapshot of this state (via side-channel leakage, VM introspection, or memory forensics on a compromised host), the entire forward output stream is compromised. This is not a theoretical concern. CVE-2023-31484 and related vulnerabilities have demonstrated that CSPRNG state can leak through unexpected vectors.

A quantum random number generator eliminates this attack class entirely. QRNG output is non-deterministic—there is no state to recover, no algorithm to reverse, no seed to compromise. Each bit is generated from a quantum mechanical process (photon polarization measurement, vacuum fluctuation sampling, or radioactive decay timing) that is provably unpredictable under the laws of physics, not merely computationally hard to predict.

Harvest now, decrypt later (HNDL)

The HNDL threat model applies to entropy as well as ciphertext. An adversary who captures encrypted identity traffic today—including the nonces, IVs, and session tokens generated by CSPRNGs—can, in a post-quantum future, potentially reconstruct CSPRNG internal states and re-derive key material.

This may sound speculative. It is not. The NSA has publicly stated that national security systems should begin transitioning to quantum-resistant algorithms. The CNSA 2.0 timeline mandates post-quantum cryptography for all new systems by 2030. If the entropy source feeding those algorithms is deterministic, the quantum resistance of the algorithm itself is undermined.

QRNG mechanisms

A QRNG derives randomness from quantum mechanical phenomena. The three dominant approaches in commercial hardware are:

1. Photon detection (shot noise)

A laser emits photons toward a beam splitter. Each photon has a quantum-mechanically random probability of being transmitted or reflected. A pair of single-photon detectors records the outcome. The raw bitstream—transmitted = 1, reflected = 0—is provably random under the Born rule of quantum mechanics.

This is the mechanism used by ID Quantique (Quantis QRNG chips) and Quside—both of which have achieved Common Criteria certification for their entropy sources.

2. Vacuum fluctuation sampling

Even in a perfect vacuum, quantum field theory predicts non-zero energy fluctuations—the Casimir effect provides experimental confirmation. Homodyne detection of these vacuum fluctuations produces a continuous random signal. Australian National University's QRNG uses this approach, providing a publicly accessible API for quantum random numbers.

3. Photonic quantum circuits

Quantum Computing Inc. (QCi) operates a uQRNG platform based on photonic quantum circuits. Unlike discrete photon detection, this approach uses continuous-variable quantum states processed through integrated photonic chips, achieving throughput rates suitable for enterprise workloads.

All three approaches share a critical property: the randomness is non-algorithmic. There is no seed, no state, no deterministic function. The output is a direct measurement of a quantum process. An adversary with unlimited classical or quantum computational power cannot predict the next bit, because the next bit does not exist until the measurement occurs.

QRNG vs. CSPRNG: The comparison

The optimal architecture is QRNG-seeded CSPRNG rather than QRNG or CSPRNG: quantum entropy provides the seed, and a deterministic DRBG provides the throughput.

The architecture: Seed and stretch

PasskeyBridge does not call a QRNG API for every byte of randomness it needs. That would be operationally impractical—network latency to external entropy sources ranges from 5ms to 200ms depending on provider and geography, and identity operations must complete within a 50ms budget.

Instead, PasskeyBridge implements a Seed and Stretch architecture:

1. Seed—Pull a 256-bit quantum entropy seed from the highest-available QRNG provider.
2. Mix—XOR the quantum seed with 256 bits of local CSPRNG entropy. This guarantees uniqueness even if the QRNG provider returns cached or degraded entropy.
3. Derive—Import the mixed seed as an AES-256-CTR key via the Web Crypto API.
4. Stretch—Use AES-CTR encryption of zero-filled blocks to generate high-throughput pseudo-random output. The counter increments per block, providing deterministic expansion from the quantum seed.
5. Re-seed—After 1,000 requests or 60 seconds (whichever comes first), fetch a fresh quantum seed and re-initialize the DRBG.

This is not a novel construction. It follows the NIST SP 800-90A CTR_DRBG specification, with one critical modification: the seed entropy is quantum-derived rather than OS-derived.

The practical difference: every nonce, every IV, every challenge generated by PasskeyBridge inherits the non-deterministic properties of its quantum seed—while maintaining the throughput characteristics of a hardware-accelerated AES-CTR stream.

The provider hierarchy

Not every deployment environment has access to dedicated QRNG hardware. PasskeyBridge implements a four-tier entropy hierarchy, tried in priority order:

If a higher-priority provider is unavailable (network failure, rate limit, missing API key), the system falls through to the next tier. The fallback to CSPRNG ensures that entropy generation never blocks—but every seed is logged to an append-only audit table with the source provider, a SHA-384 hash of the mixed entropy (never the raw seed), and a timestamp. This provides SOC 2 auditors with provable evidence of entropy provenance without exposing key material.

Identity's entropy requirements

The argument for QRNG entropy is not equally compelling for every application. A static website serving cached content does not need quantum entropy for its TLS session tickets. A gaming application generating loot drops can use Math.random() without existential risk.

Identity is different. Identity systems generate secrets that protect other secrets. The chain of trust looks like this:

QRNG seed → DRBG key → Session nonce → WebAuthn challenge → Passkey binding → User identity

If the nonce in a WebAuthn authentication challenge is predictable, an attacker can pre-compute the expected assertion and forge authentication. If the IV in an AES-256-GCM BLAST tunnel is reused, the encryption is catastrophically broken—Joux's forbidden attack recovers the authentication key from two messages encrypted under the same IV.

These are the documented failure modes of deterministic entropy in cryptographic protocols, not hypothetical attacks. QRNG seeding does not make these attacks "harder"—it makes them physically impossible, because the entropy source is non-deterministic by the laws of quantum mechanics rather than the computational difficulty of a mathematical problem.

The compliance angle

Regulatory frameworks are beginning to acknowledge entropy quality as an auditable control:

• NIST SP 800-90C (Draft)—Recommendation for Random Bit Generator Constructions—explicitly discusses entropy source quality and DRBG seeding requirements.
• Common Criteria NDPP: Network Device Protection Profiles require entropy sources that meet minimum entropy density thresholds.
• FIPS 140-3: The latest FIPS cryptographic module validation standard includes enhanced entropy source testing requirements under SP 800-90B.

For enterprises pursuing SOC 2 Type II or FedRAMP authorization, demonstrating that cryptographic entropy is sourced from a quantum process—with auditable provenance records—is a control that auditors increasingly recognize and value.

PasskeyBridge logs every DRBG reseed event to the shield_entropy_pool table: source provider, seed size, SHA-384 hash of mixed entropy, and timestamp. This creates an unbroken audit chain from quantum source to cryptographic operation—without ever exposing raw key material.

The counterargument

The strongest counterargument is simple: modern CSPRNGs, properly seeded, have never been broken in practice. /dev/urandom on a well-maintained Linux system, seeded from hardware interrupt timings and RDRAND, produces output that passes every statistical test in the NIST SP 800-22 suite. No published attack recovers CSPRNG state from output alone.

This argument is correct—for classical adversaries.

The question is whether identity systems should be designed for the threat model of today or the threat model of 2030. PasskeyBridge's answer is unambiguous. We implement ML-DSA-65 post-quantum signatures not because classical signatures are broken today, but because the transition window is closing. We implement QRNG-seeded entropy not because CSPRNGs have been compromised, but because the cost of quantum seeding is negligible and the security delta is permanent.

The Seed and Stretch architecture adds approximately 50ms of latency per reseed cycle (amortized across 1,000 requests) and zero latency to individual random byte generation. The operational cost is a single API call every 60 seconds. The security benefit is non-deterministic entropy provenance for every cryptographic operation in the platform.

That is a free upgrade.

Practical implications for platform engineers

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

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

1. How often do you reseed? A DRBG that seeds once at process startup and never reseeds is a single point of failure. A compromised seed means every subsequent output is deterministic.

1. Is entropy provenance auditable? Can you demonstrate to a SOC 2 auditor exactly which entropy source produced the seed for a given cryptographic operation? If not, your entropy is a black box.

1. What is your quantum readiness posture? CNSA 2.0 mandates post-quantum cryptography by 2030. Post-quantum algorithms with classical entropy is an incomplete migration.

1. Do you mix entropy sources? A single-source dependency—even on a QRNG—is a single point of failure. XOR-mixing quantum and classical entropy guarantees security under the stronger of the two assumptions.

PasskeyBridge answers all five questions affirmatively. The internal QRNG-DRBG module implements Seed and Stretch with a four-tier provider hierarchy, 60-second reseed intervals, full audit logging, and XOR-mixed quantum-classical entropy.

Deterministic derivation from quantum seeds

The next frontier is deterministic key derivation from quantum-seeded master material. PasskeyBridge already uses HMAC-SHA-256 deterministic derivation for ML-DSA-65 key pairs—deriving signing keys from a master seed rather than generating them independently. When that master seed is quantum-derived, the entire key hierarchy inherits quantum entropy properties.

This creates a clean separation of concerns: quantum hardware provides the entropy, deterministic algorithms provide the structure, and post-quantum signatures provide the longevity. The entropy is non-deterministic. The derivation is reproducible. The signatures are quantum-resistant. Each layer addresses a distinct threat.

Identity infrastructure built for the next decade cannot afford to treat entropy as an implementation detail. It is the foundation of every secret, every proof, and every trust decision the platform makes. Pseudo-random is not random enough.

Explore how PasskeyBridge implements quantum-resilient identity →

Start free · Test the API