Imagine a bank that locks a billion dollars behind a private key and then tells the world the key was born from pure quantum physics. Not a human typing numbers. Not a normal computer. A device-independent quantum random number generator. The kind that runs a tiny physics experiment, checks a Bell inequality, and promises the bits could never be guessed by anyone, not even a future quantum computer.

That promise sounds excellent until you notice the experiment never actually happened. The entire "quantum" process is a deterministic function of a publicly known seed. Anyone who can read the seed can replay the math and recover the key.

This article walks through how a CHSH-style randomness beacon is supposed to work, where the trust assumptions break, a synthetic example of the failure, and the practical fixes that actually matter.

What Is a Device-Independent QRNG, Anyway?

A classical random number generator is just code that expands a seed into a longer string. If the seed is weak or leaked, the output is weak.

A quantum random number generator tries to do better by measuring a physical process that is supposed to be unpredictable: photon polarization, vacuum fluctuations, radioactive decay, that sort of thing.

Device-independent designs go one step further. They do not trust the hardware at all. Instead they run a Bell test (usually a CHSH game) between two or more measurement parties. If the observed correlations violate the classical bound hard enough, the theory says some of the output bits must contain genuine randomness, even if the devices themselves are malicious or broken.

The classic CHSH inequality looks like this:

[ S = E(0,0) + E(0,1) + E(1,0) - E(1,1) ]

Classical local realism caps (S) at 2. Quantum mechanics allows up to (2\sqrt{2} \approx 2.828). A solid experimental violation is taken as evidence that the outcomes cannot be fully predetermined by any local hidden variables.

In a real lab this is expensive and careful work. In software marketing it is often a slide that says "Bell-certified" and then a deterministic loop that nobody audits.

Why Should You Care?

Because the phrase "device-independent quantum randomness" is starting to appear in product pages for hardware security modules, cold wallets, and high-value key ceremonies. When the marketing is louder than the implementation, the gap becomes an attack surface.

Places this shows up:

Cold-wallet key generation that claims quantum origin
"Unpredictable" nonces or salts produced by a software beacon
Lottery or fairness systems that publish a CHSH score for public verification
Any protocol that treats a public seed plus a deterministic CHSH simulation as equivalent to a real quantum experiment

Consequences when the beacon is deterministic:

Full recovery of every "random" output once the seed is known
Private keys that were never private
False confidence that survives audits looking only at the CHSH score
Regulatory or insurance language that still claims "quantum-grade" security

The CHSH number can look perfect while the underlying process remains pure classical code.

How the Beacon Is Supposed to Work

A typical software implementation of a CHSH randomness beacon looks roughly like this:

Start with a 32-byte seed (H).
For each trial (i = 0 \dots N-1):
- Derive trial bytes: (tb = \mathrm{SHA256}(H | \text{"|trial|"} | i))
- Extract measurement settings (a, b) from the first byte
- Extract a uniform sample (\lambda \in [0,1)) from later bytes
- Sample outcomes ((x, y)) according to the ideal quantum correlators (E(a,b))
Concatenate all outcome pairs into a long string.
Hash that string to produce the final randomness (W).

The correlators are chosen so that the expected CHSH value sits near the Tsirelson bound. When (N) is large (say 1024 trials) the measured (S) almost always exceeds the classical limit of 2.0. The system then declares the output "device-independent" and hands (W) to a key derivation function.

On paper this looks rigorous. In practice every step after the seed is pure deterministic math. There is no photon, no detector, no loophole, and no need for any quantum hardware. The CHSH score is just a side effect of sampling from the ideal quantum distribution with a PRNG.

Worked Example: The Public Seed That Unlocked Everything

Consider a synthetic cold-wallet system. The operators publish a generation block hash (a public value everyone can see) and claim the private key was derived from a device-independent QRNG seeded by that hash. The public key is also published so the world can verify the funds are still sitting there.

An analyst notices three things:

The beacon parameters are fully documented (number of trials, exact correlators, exact sampling rule).
The seed is either the published block hash itself or a trivial function of it.
The final output (W) is used, possibly with a simple hash or modular reduction, as the secp256k1 private key.

Because every trial is determined by the seed, the entire outcome string can be recomputed offline. One SHA-256 at the end produces (W). That value is the private key.

No quantum computer is required. No side-channel is required. The only "attack" is reading the public documentation and running the same math the system already ran.

The lazy corner that was cut was treating a deterministic simulation of a Bell test as if it were the physical experiment. The CHSH score looked great because the code was written to make the score look great. The randomness was never there.

Adjacent variants of the same mistake:

Seeding the beacon from a predictable timestamp or low-entropy system state
Publishing the seed for "public verifiability" while still using the same seed for the secret key
Using a weak extractor or no extractor at all after the outcome string
Trusting the CHSH number alone without checking whether the devices ever left the realm of classical simulation

Vulnerable Code Example

A simplified Python version of the deterministic beacon:

from hashlib import sha256
import struct

def generate_w(seed: bytes, trials: int = 1024) -> str:
    E = {
        (0, 0):  1 / (2 ** 0.5),
        (0, 1):  1 / (2 ** 0.5),
        (1, 0):  1 / (2 ** 0.5),
        (1, 1): -1 / (2 ** 0.5),
    }
    outcomes = []
    for i in range(trials):
        tb = sha256(seed + b"|trial|" + i.to_bytes(4, "big")).digest()
        a = tb[0] & 1
        b = (tb[0] >> 1) & 1
        lam = int.from_bytes(tb[8:16], "big") / 2**64
        pairs = [(0,0), (0,1), (1,0), (1,1)]
        cum = 0.0
        chosen = pairs[-1]
        for x, y in pairs:
            p = (1 + ((-1)**(x + y)) * E[(a, b)]) / 4
            cum += p
            if lam < cum:
                chosen = (x, y)
                break
        outcomes.append(f"{chosen[0]}{chosen[1]}")
    return sha256("".join(outcomes).encode()).hexdigest()

The seed is public or recoverable. The output is therefore public or recoverable.

Feeding that output straight into a private-key slot is the vulnerability.

A patched version does not pretend the simulation is quantum:

from secrets import token_bytes
from hashlib import sha256

def generate_private_key() -> bytes:
    # Real entropy from the OS (or a properly engineered QRNG with audited hardware)
    raw = token_bytes(32)
    # Optional: domain-separated KDF
    return sha256(b"wallet-key|" + raw).digest()

No public seed, no deterministic replay, no fake Bell score used as a security claim.

Defense / How to Fix

Never use a public or recoverable value as the seed for secret key material. If the seed is known, the entire beacon output is known.
Separate the randomness source from the verification score. A CHSH score can be useful for monitoring a real physical device. It is not a substitute for the entropy itself.
If you run a software simulation for testing or education, label it as a simulation. Do not publish marketing language that implies physical quantum origin.
Prefer OS-provided CSPRNG interfaces ( getrandom , secrets , CryptGenRandom , etc.) for key generation unless you have a documented, audited hardware QRNG with a clear trust model.
When using a real QRNG, keep the raw entropy private. Public randomness beacons (such as those used for lotteries or consensus) are a different threat model from secret key generation.
Audit the full data path. Seed → trials → outcomes → extractor → private key. Any point where the seed becomes public is a complete break for secret-key use cases.
Do not treat a high CHSH number as proof of secrecy. It is evidence of non-classical correlations under the assumptions of the Bell test. Those assumptions do not hold for a pure software simulation.

Final Thoughts

Calling a deterministic hash loop "device-independent quantum randomness" is a category error. The math can reproduce the ideal correlators and produce a convincing CHSH score. That does not invent entropy that was never present.

If the seed is public, the key is public. The physics never entered the room. The safest quantum key is the one that actually needed a quantum experiment, not the one that only needed a few lines of SHA-256 and a marketing slide.

Treat every randomness claim the same way you treat every other cryptographic claim: demand the threat model, the entropy source, and the concrete assumptions. Fancy labels do not generate bits.