QRNG-seeded ML-KEM handshake
A Server holds a QRNG-seeded ML-KEM-768 keypair; a Client encapsulates to derive a shared secret; both derive an AES-GCM key and exchange one encrypted message — no page reload. The API key that drives this stays server-side; the browser only ever sees the same responses a keyed client would.
Where this maps to networking
Honest framing: QRNG supplies entropy; ML-KEM supplies the quantum resistance. Five places that entropy plugs into networking — one sentence each, full write-up in shared/docs/networking-demo.md.
Ephemeral TLS/VPN keys
QRNG-seeded entropy strengthens the randomness behind ephemeral session keys, supporting forward secrecy — it does not make the handshake protocol itself quantum-resistant.
WireGuard ephemeral keys
The same QRNG→DRBG entropy chain could seed WireGuard's ephemeral X25519 keypairs; this demo shows the entropy path with ML-KEM, not a WireGuard integration.
SDN control-plane seeding / moving-target defence
Centralized quantum entropy can seed the randomized re-keying or address/path rotation SDN controllers use for moving-target defence — again, entropy quality, not a new protocol.
ECMP hash salt
A quantum-seeded random salt for ECMP hashing reduces predictable flow-collision patterns across load-balanced paths — it improves salt unpredictability, not the hashing algorithm.
IoT seed distribution
Central quantum entropy, distributed to weak-RNG edge devices via API-key tiers, upgrades the entropy those devices seed their own local RNGs with — the devices still do the RNG work.