Your HSM Already Has a TRNG. It Still Can't Prove Anything.

1. "We have real randomness" is not a security pitch

Linux already ships /dev/random, getrandom(), and CPU instructions like RDRAND. Most HSMs, TPMs, and cloud KMS providers embed their own hardware TRNGs. Telling a security engineer "our entropy is real" next to that isn't a differentiator: theirs already is, most of the time.

The question that actually matters is different: what happens if that one source turns out to be flawed, backdoored, or just wrong, and how would anyone know? Dual_EC_DRBG shipped as a NIST-endorsed PRNG with a suspected backdoor for years before it was proven. The Linux kernel still refuses to trust RDRAND alone, mixing it into the pool instead of using it directly.

2. Don't replace your RNG. Mix an independent one into it.

Galactropy isn't a drop-in replacement for your HSM or TPM. It's a second, physically independent entropy source: radio noise sampled by SDR hardware and conditioned with SHA-512, folded into whatever pool already feeds your key generation. This is standard practice for combining entropy sources: as long as one of the inputs is genuinely unpredictable, the combined output is too, regardless of what happens to the others.

3. Independent isn't enough. It has to be verifiable too.

An HSM or cloud KMS's RNG is a closed box: you trust the vendor's certificate and nothing else. Every batch Galactropy's nodes produce is checked with Dieharder, ENT, and rngtest, chained with Ed25519 signatures, and anchored to the Bitcoin blockchain via OpenTimestamps, so the record can't be quietly edited after the fact, by us or anyone else.

4. Mixing it in takes one line

Pull raw bytes from the public API and feed them into your existing entropy pool before deriving keys:

curl -s "https://galactropy.com/raw?bytes=512" >> /dev/urandom