Key exchange and the hybrid handshake

In Diffie–Hellman both sides are equal. Each publishes a public value, mixes the other's value with its own secret, and both reach the same result. A key-encapsulation mechanism is asymmetric instead. The receiver publishes an encapsulation key. The sender uses it to produce a ciphertext plus a fresh shared secret. The receiver feeds the ciphertext and its decapsulation key into decapsulation and gets the same secret back.

X25519 fits the same shape if you squint: the sender's ephemeral public key plays the part of the ciphertext. That is how protocols slot ML-KEM in where X25519 used to be.

ML-KEM, standardised from CRYSTALS-Kyber, relies on the Module-LWE problem, the same family as ML-DSA. The public key is a seed that expands into a matrix A, plus t = A·s + e for short secret vectors s and e. Encapsulation picks a random 32-byte message, encrypts it under the public key with randomness derived from that message, and hashes the message into the shared secret.

Decapsulation decrypts, then re-encrypts and checks that it reproduces the exact ciphertext it received. This is the Fujisaki–Okamoto transform. If the check fails, ML-KEM does not report an error. It returns a pseudorandom secret derived from a hidden value and the bad ciphertext. This is called implicit rejection: an attacker who tampers with ciphertexts learns nothing from the responses. The Lab's Tamper ciphertext button shows it happening.

The classical half is known to fall to a future quantum computer. The post-quantum half is newer mathematics with less time under attack. A hybrid runs both and derives the session key from both secrets, so an attacker has to break both. The cost is roughly 32 extra bytes in each direction on top of ML-KEM.

The deployed example is X25519MLKEM768 in TLS 1.3. The client sends an ML-KEM-768 encapsulation key followed by an X25519 share (1,216 bytes). The server answers with an ML-KEM ciphertext and its X25519 share (1,120 bytes). The two secrets are concatenated, ML-KEM first, and fed into the normal TLS key schedule. Chrome turned it on by default in late 2024, and major CDNs accept it. OpenSSH went the same way: its default key exchange became a hybrid of Streamlined NTRU Prime and X25519 in version 9.0, then mlkem768x25519-sha256 in version 10.0.

A hybrid TLS handshake carries a little over 2 KB more than a classical one. That is negligible for bandwidth, but it can push a ClientHello past a single packet. Some older middleboxes mishandled split ClientHellos when browsers first rolled this out, which is worth knowing if you run your own load balancers or firewalls.

Solana itself encrypts nothing. Transactions and state are public by design, so “store now, decrypt later” does not apply to the ledger. It applies to everything around it:

• TLS between users, your frontend, your APIs and your RPC provider.
• Wallet-to-app sessions, such as the encrypted channel in the Mobile Wallet Adapter protocol, which uses classical ECDH today.
• Private order flow and transaction submission paths that are meant to stay confidential until execution.
• Encrypted messaging between wallets, and encrypted backups of seed phrases or key shares.

The last item matters most. An encrypted seed backup protected by classical key exchange is a perfect harvest-now target. Steps you can take today: make sure your TLS terminators support X25519MLKEM768, and use a hybrid KEM for any application-level encryption you control.