What We Use in KEIBIDROP
KEIBIDROP uses a hybrid key exchange combining two KEMs:
- ML-KEM-1024 (formerly Kyber-1024, NIST FIPS 203) -- lattice-based, post-quantum secure
- X25519 -- elliptic curve Diffie-Hellman, classical security
Both KEMs produce independent shared secrets. These are combined via HKDF-SHA256(mlkem_secret || x25519_secret) to derive the session key. The session is then encrypted with ChaCha20-Poly1305. If ML-KEM is broken, X25519 still protects the session. If X25519 is broken by a quantum computer, ML-KEM still protects it. Both must be broken simultaneously to compromise a session.
The handshake runs inside custom gRPC transport credentials, adding ~3ms of overhead per connection. Details in the gRPC post-quantum blog post.
What We Don't Use (Yet)
HQC (code-based KEM) was a NIST Round 4 alternate. Adding it as a third KEM would diversify the cryptographic assumptions (lattice + code + elliptic curve). We haven't implemented it because NIST standardization was not finalized at time of writing, and two KEMs already provide defense in depth.
ML-DSA (formerly Dilithium, NIST FIPS 204) for post-quantum signatures is planned but not implemented. Currently, peer identity is verified through out-of-band fingerprint comparison, not digital signatures. Adding ML-DSA would allow signature-based authentication without a certificate authority.
Why Hybrid
ML-KEM is new. The lattice problems it relies on have been studied for decades, but the specific parameter sets are recent. Running ML-KEM alone would be a bet that no classical attack surfaces in the coming years. Running X25519 alone ignores the quantum threat. The hybrid approach means we don't have to bet on either assumption being correct.
This is the same approach recommended by NIST, BSI, and ANSSI for transition-period systems.