ML-KEM and hybrid key exchange (X25519 + ML-KEM-768)

Why key exchange goes first#

Chapter 01 separated two kinds of risk. Signatures only become forgeable once a cryptographically relevant quantum computer exists. Key exchange is different: an adversary can record an encrypted session today and decrypt it later, once the classical key agreement can be broken. That makes key exchange the part of the stack where waiting has a real cost, and it is why the first large post-quantum deployments on the internet were key exchange, not signatures.

KEMs vs. Diffie–Hellman#

X25519 (RFC 7748) is a Diffie–Hellman function. Each party has a 32-byte private scalar and publishes a 32-byte public key. Either side can combine its own private key with the other's public key to get the same 32-byte shared secret. The operation is symmetric and can even be non-interactive: if you already know someone's long-term public key, you can derive a shared secret with them without sending anything first.

A key-encapsulation mechanism (KEM) has a different shape, defined by three algorithms:

KeyGen()        → (ek, dk)     encapsulation key (public), decapsulation key (secret)
Encaps(ek)      → (K, c)       shared secret K, ciphertext c   — run by the sender
Decaps(dk, c)   → K            same shared secret               — run by the receiver

One party publishes an encapsulation key; the other uses it to produce a fresh random shared secret plus a ciphertext that only the key holder can open. There is no symmetric "combine my secret with your public key" step. Protocols that relied on that property, such as static-static Diffie–Hellman or some authenticated key-exchange patterns, cannot swap in a KEM without redesign. Ephemeral key exchange, as in TLS 1.3, maps across cleanly: the client sends an encapsulation key, the server replies with a ciphertext.

ML-KEM#

ML-KEM, standardised in FIPS 203 (August 2024), is derived from CRYSTALS-Kyber. Its security rests on the Module Learning With Errors problem, the same family as ML-DSA's key security. Internally it is a public-key encryption scheme wrapped in a variant of the Fujisaki–Okamoto transform, which makes it secure against active (chosen-ciphertext) attacks. On a malformed ciphertext, decapsulation does not return an error; it returns a pseudorandom value derived from a secret, an approach called implicit rejection that avoids leaking information through error handling.

ML-KEM-768 is the common default: it targets category 3 and its sizes are comfortable for a network handshake. It is also fast. Key generation, encapsulation and decapsulation are cheap compared with the network round trip they ride on. As with signatures, the cost is bytes, not CPU, but for key exchange the bytes are paid once per session rather than once per transaction.

Hybrid: X25519 + ML-KEM-768#

ML-KEM is young compared with elliptic-curve cryptography. Its underlying problem has been studied for many years, but implementations are newer and the algorithm has had less time in deployment. Hybrid key exchange hedges that risk: run both X25519 and ML-KEM-768 and derive the session key from both shared secrets. An attacker then needs to break both. A quantum attacker who can break X25519 still faces ML-KEM, and a hypothetical classical break of ML-KEM still leaves X25519 standing.

client → server   key_share = ML-KEM-768 ek (1184 B) ‖ X25519 pub (32 B)   = 1216 B
server → client   key_share = ML-KEM-768 ct (1088 B) ‖ X25519 pub (32 B)   = 1120 B

both sides        shared = ML-KEM K (32 B) ‖ X25519 K (32 B)
                  → fed into the TLS 1.3 key schedule (HKDF), bound to the transcript

This exact combination is specified for TLS 1.3 in an IETF Internet-Draft and has already been deployed at scale by major browsers and content-delivery networks. For a team terminating TLS, enabling it is often a configuration change in a recent TLS library or load balancer, with the cost being about 2.2 KB of extra handshake bytes in total (1,184 + 1,088). Check that middleboxes on your path accept the larger ClientHello, which can now span more than one packet.

Outside TLS, hybrid combining needs more care. TLS gets away with simple concatenation because its key schedule hashes the whole handshake transcript, including both public keys and the ciphertext. If you design your own protocol, use a published hybrid KEM combiner that binds the ciphertexts and public keys into the derived key, rather than hashing the two secrets alone. Better still, use an existing protocol rather than designing one.

Messaging has moved the same way. Signal's PQXDH and Apple's PQ3 for iMessage are published examples of protocols that add a lattice KEM alongside their existing elliptic-curve exchange.

Where this touches a Solana product#

Solana transactions are public. Their contents are not encrypted, so there is nothing for a quantum adversary to decrypt in ordinary transaction data. Key exchange matters in the systems around the chain:

• RPC and API traffic. Requests from your frontend or backend to RPC providers, indexers and your own APIs run over TLS. Session tokens, user identifiers and request patterns are confidential even when the eventual transaction is not.
• Wallet-to-app channels. Protocols that connect wallets to apps commonly establish an encrypted session with elliptic-curve Diffie–Hellman. Anything secret sent over that channel is harvestable.
• Encrypted data stored on-chain. If an app encrypts a memo or account data to a key derived from an X25519 exchange and writes it on-chain, every copy of the ledger is a permanent recording. This is the purest form of harvest now, decrypt later.
• Off-chain metadata and messaging. DMs, encrypted uploads, KYC records and anything with a long secrecy lifetime that travels over classical key exchange.
• Backups and key transport. Any flow that moves seed material or secret keys between devices or services over a classical channel.

A useful triage question is: "If this ciphertext were published in ten years, would it still hurt?" If yes, prioritise moving that channel to hybrid key exchange. The Readiness check asks exactly this in its data-at-rest section.