Post-Quantum Key Exchange with ML-KEM
Confidential channels use ML-KEM in a hybrid with an elliptic-curve exchange, so a session stays secure unless both the classical and the quantum-safe scheme fail.
Lattice-based key encapsulation
ML-KEM (FIPS 203, from CRYSTALS-Kyber) is a module-lattice key-encapsulation mechanism. One party publishes a public key; the other encapsulates a random shared secret to it and returns a ciphertext; both derive the same symmetric key. Its security rests on the hardness of the module learning-with-errors problem, which no known quantum algorithm breaks efficiently. Kronos uses it to establish the symmetric keys protecting exported telemetry and cross-boundary sessions.
Hybrid, not replacement
During transition Kronos runs a hybrid: the session key is derived from both an X25519 (classical) exchange and an ML-KEM encapsulation. An attacker must break both to recover the key. This guards against an as-yet-undiscovered flaw in the newer lattice scheme while still defeating a future quantum adversary against the classical half.
# Hybrid key derivation: classical XOR quantum-safe, both required
def hybrid_session_key(peer):
ss_classical = x25519(our_eph_priv, peer.x25519_pub) # ECDH
ct, ss_pq = ml_kem_encaps(peer.mlkem_pub) # FIPS 203
send(ct)
# Both secrets feed the KDF; compromise of one is not enough
return hkdf_sha384(ss_classical + ss_pq, info=b'kronos-ot-v1')
Parameter choice and cost
- Category-3 parameters (ML-KEM-768) balance margin against the larger key/ciphertext sizes lattice schemes carry.
- Larger handshakes cost bandwidth; on the diode export path this is budgeted and acceptable.
- On resource-limited FPGA links, key reuse windows and session lifetimes are tuned to keep handshake overhead bounded - see crypto agility.
Design status
Hybrid ML-KEM is implemented in the twin's transport layer and tested for interoperability and performance. Deployment on FOAK OT links and validation of handshake cost on the edge FPGAs is part of the 2027 build; no live reactor uses it yet.