Quantum V^

How does the eavesdropper detection work in your QES Key Exchange?

Our protocol differs from traditional E91: Instead of separate measurements, both parties use the same GHZ measurement (shared state architecture). This eliminates the need for basis comparison and achieves 0% error rate.

Eavesdropper Detection: We use parity comparison over classical channels. Random bits are sampled from raw keys, and parity is compared without revealing the actual key bits. Any eavesdropper measurement disturbs the GHZ state, introducing detectable errors.

Detection Probability: For our parameters (100 samples, 69% fidelity), detection probability is near-certain: P_detect ≥ 1 - exp(-620) ≈ 1.0

Key Distribution: All communication is over classical channels only. The quantum path is only for GHZ state generation (single execution), then both parties extract keys from the same measurement data.

What is Entropy-as-a-Service?

QES-256 — Quantum Entropy Source: Every IBM Quantum job produces a QES-256 key — a 32-byte hardware-derived value with 2²⁵⁶ possible values, the same key size as AES-256. QES-KX and the QRNG API both emit QES-256 keys — one entropy standard for both. (Recluda sign-in approval doesn't use QES-256: its keys are created and kept in the iPhone's Secure Enclave.) Organizations already running AES-256 can source keys from real quantum hardware without changing their encryption stack. Classical PRNGs are deterministic and software-based; QES-256 keys trace back to a verifiable IBM Quantum job ID — auditable entropy provenance no classical system can provide.

• 432 independent jobs validated on ibm_marrakesh
• 81.3% entropy efficiency (9.76 of 12 bits mean) — hardware-measured
• Zero migration cost — drop-in quantum entropy for any AES-256 deployment

Practical: Generation time is <0.01s (simulator) or 30–90s (hardware). Every key ships with a verifiable IBM Quantum job ID.

Have you developed formal security proofs?

For the key exchange we deploy, security rests on standard, well-analyzed constructions rather than an information-theoretic proof of our own: X25519 (classical ECDH) combined with ML-KEM-768 (NIST FIPS 203 post-quantum) via HKDF. Breaking the derived key requires breaking both, independently.

Zero-trust relay: the relay server never receives the pre-shared secret, either party's private key, or the derived key — verified by an automated test that a passive observer with everything actually transmitted still cannot reconstruct the key.

Quantum-seeded entropy: ephemeral key material is seeded from real IBM Quantum hardware randomness, traceable to a verifiable job ID.

We separately run GHZ entanglement experiments on real quantum hardware (see hardware validation) — genuine physics results, but a research demonstration, not the mechanism securing this key exchange. An earlier design tried to use a shared GHZ measurement as the key-exchange step itself; that turned out to be undeliverable as a zero-trust primitive on cloud quantum hardware, since the party submitting the circuit job sees the entire measurement outcome directly. We retracted that claim rather than keep it live.

Computational security (Echo Resonance layer): Each session produces a QES-256 key — a 32-byte IBM Quantum hardware-derived key with 2²⁵⁶ possible values, equivalent to AES-256 key space.