Abstract

Most discussion of ML-KEM deployment centres on the TLS handshake, where a transcript hash binds everything. This piece examines three other places ML-KEM now lives and asks of each the same question: what does the construction assume of the KEM, and what does it supply for itself? Hybrid Public Key Encryption with post-quantum KEMs encrypts to a static key, stores private keys as seeds, relies on ML-KEM's binding where its classical counterpart built binding into the KEM, and gives up the authenticated mode. X-Wing, a hybrid of ML-KEM-768 and X25519, omits the ML-KEM ciphertext from its combiner on the strength of a ciphertext second-preimage property proved specifically for ML-KEM, and draws its security analysis tightly around a single 32-byte seed. SSH's ML-KEM hybrid methods hash the two secrets alone and obtain binding from the server's signature over the exchange hash. The piece assembles these into an assumptions ledger, applies it to agent messaging, private inference requests and agent-driven shells, and closes by integrating binding, key provenance, verification scope and construction assumptions into one decision procedure for an agent platform.

The same engine can power a car, a boat and a generator, and in each the engine's specifications matter differently, because the chassis around it supplies different things: steering, a hull, a frame bolted to the floor. ML-KEM is in the same position. In a TLS handshake, the surrounding protocol hashes every message into the key schedule, so the KEM is asked only to keep its secret hidden. Wrap it in a public-key encryption scheme, a self-contained hybrid KEM, or a remote-shell key exchange, and the wrapper asks for more, or less, or different things. Knowing exactly what each wrapper asks is what lets an engineer reuse it safely, and what tells them which substitutions would quietly break it.

Beyond the handshake everyone studies

In TLS 1.3, ML-KEM appears inside hybrid key-exchange groups that pair it with an elliptic-curve exchange, and the protocol's key schedule absorbs a hash of the whole transcript, so binding and context come from the protocol rather than the KEM. That arrangement is well analysed and is not the subject here. The subject is the three other standardized or nearly standardized constructions an engineer building agent systems is now likely to meet: Hybrid Public Key Encryption, known as HPKE; the X-Wing hybrid KEM; and the ML-KEM hybrid key-exchange methods for the Secure Shell protocol, SSH.

They place ML-KEM in three different roles. HPKE uses it to encrypt to a long-lived recipient key, one message at a time, with no interaction. X-Wing packages ML-KEM and X25519 into a single KEM meant to be dropped into any protocol that expects one. SSH uses it inside an interactive exchange whose result the server signs. Each role changes which properties the construction needs from the KEM, and the construction's authors have, in each case, written down what they rely on. Reading those statements side by side is the most direct way to see what ML-KEM is being trusted for.

Three properties recur throughout. IND-CCA, indistinguishability under chosen-ciphertext attack, says the shared secret stays hidden even from an attacker who can obtain decapsulations of other ciphertexts. Binding says the shared secret identifies the public key and ciphertext that produced it; it comes in leakage and malicious strengths, depending on whether the attacker merely learns keys or constructs them. Ciphertext second-preimage resistance, introduced for X-Wing, says nobody can find a second ciphertext that decapsulates to the same secret as a given one, even knowing the private key.

It also helps to know where ML-KEM is not a drop-in at all. The CFRG security-considerations draft points out that a KEM differs structurally from Diffie-Hellman: the ciphertext is computed from one specific public key, and the encapsulating party cannot start until it has that key. ML-KEM therefore replaces ephemeral-ephemeral exchanges, as in TLS and SSH, and static-ephemeral ones, as in HPKE, directly. It is not a drop-in for designs that rely on both parties holding long-term keys and combining them non-interactively, such as the Diffie-Hellman ratchet in Signal or the implicit authentication in Noise and WireGuard. Agent protocols modelled on those patterns need redesign, not substitution.

HPKE: encrypting to a static key

HPKE, specified in RFC 9180, combines a KEM, a key-derivation function and an authenticated cipher into a scheme that encrypts messages to a recipient's public key. Its Diffie-Hellman KEM builds the encapsulated value and the recipient's public key into the KEM's shared secret, so HPKE's key schedule can take that secret as given. The IETF document that adds post-quantum KEMs to HPKE, draft-ietf-hpke-pq, in IESG evaluation as of 2026, defines code points for ML-KEM-512, ML-KEM-768 and ML-KEM-1024 and for three hybrids, ML-KEM-768 with P-256, ML-KEM-1024 with P-384, and ML-KEM-768 with X25519, together with SHA-3 based key-derivation functions.

Three of its choices are instructive. First, an HPKE ML-KEM private key is the 64-byte seed, and decapsulation expands the seed before calling ML-KEM, so every private key HPKE handles is in the format that resists the stored-hash forgery and gives malicious-strength ciphertext binding. Second, its security considerations name two binding properties as salient for protocol design, describing them as providing assurances similar to transcript hashing: if sender and receiver hold the same key, only one encapsulation key and only one ciphertext could have produced it, even if the private key leaks later. The document states that ML-KEM and the hybrids meet these leakage-strength properties. Third, it notes that its KEMs do not support HPKE's authenticated modes, in which the sender proves its identity through the KEM itself, and points to the pre-shared-key mode or digital signatures instead.

HPKE also defines deterministic key derivation from input keying material, and the post-quantum document specifies it by deriving the 64-byte ML-KEM seed with a SHAKE256-based labelled derivation and expanding that seed with FIPS 203's internal key generation. That gives systems a clean way to derive many recipient keys, one per agent or per task, from a single master secret, with every derived key produced by honest key generation. The price is concentration: the master secret becomes the root of every key derived from it, and its compromise is the compromise of all of them.

Two properties of HPKE in general shape how ML-KEM is used inside it. RFC 9180 states that HPKE ciphertexts are not forward secret with respect to recipient compromise: whoever obtains the recipient's long-term private key can decrypt every past message sent to it. And because one static key receives ciphertexts from many senders, IND-CCA is not optional here but the whole point; the CFRG ML-KEM security-considerations draft confirms that reusing an ML-KEM public key is safe for exactly this reason. Recipient key protection and rotation therefore carry the full weight of long-term confidentiality.

A seed-format ML-KEM key produces the shared secret and the key schedule turns it into cipher keys; sender authentication is not part of this path and must come from a pre-shared key or a signature.HPKE with an ML-KEM suiteRecipient seed64-byte private keyML-KEMencapsulatesecret plusciphertextKey schedulesecret taken as givenAEAD messagesno recipient forwardsecrecy
A seed-format ML-KEM key produces the shared secret and the key schedule turns it into cipher keys; sender authentication is not part of this path and must come from a pre-shared key or a signature.

X-Wing: a hybrid that leaves out the ciphertext

Hybrid KEMs exist so that a session stays secure if either the classical or the post-quantum component holds. The general recipe, due to Giacon, Heuer and Poettering, hashes both shared secrets together with both ciphertexts, because a combiner that omits a ciphertext can be attacked through a weak component: if one KEM lets an attacker find a second ciphertext that decapsulates to the same key, the attacker can submit the modified pair to a decapsulation oracle and learn the combined key for the challenge. Including the ciphertexts rules that out, at the cost of hashing them, which for ML-KEM-768 means more than a thousand extra bytes.

X-Wing, defined by Barbosa and colleagues and specified in draft-connolly-cfrg-xwing-kem, combines ML-KEM-768 and X25519 with a SHA3-256 combiner over the two shared secrets, the X25519 ciphertext and the X25519 public key, and a fixed label. It omits the ML-KEM ciphertext and public key. The justification is a property the authors define and prove: ML-KEM-768 is ciphertext second-preimage resistant, in the random-oracle model, even against an adversary who knows the private key, because its re-encryption check forces any accepted ciphertext to be the unique encryption of the recovered message. The X25519 public key is kept in the hash as a defence against multi-target attacks, the same reason ML-KEM hashes its own public key into its derivation.

X-Wing's sizes follow from its parts: a 1,216-byte public key, a 1,120-byte ciphertext, a 32-byte shared secret and a 32-byte private key. The draft requests the HPKE KEM identifier 0x647a for X-Wing, and the HPKE post-quantum document assigns the same identifier to its ML-KEM-768 and X25519 hybrid, drawn from the IRTF's concrete hybrid-KEM specification, which sits alongside a generic framework for building such hybrids. For an engineer the practical message is that an X25519 and ML-KEM-768 hybrid is converging on one well-analysed construction across contexts, which is exactly what a custom agent channel should reuse.

Two warnings in the draft define X-Wing's scope. Its security relies on the specifics of ML-KEM's Fujisaki-Okamoto variant, and the draft states that the combiner cannot be assumed secure with different KEMs, because it is not known to be safe to omit the post-quantum ciphertext in general. And its private key is a single 32-byte seed, expanded with SHAKE256 into ML-KEM's two seeds and the X25519 private key; the draft forbids transmitting the expanded form between implementations, because the binding analysis, under which it claims malicious-strength binding of the key to both public key and ciphertext, does not hold for it. X-Wing is efficient precisely because it is specific, and it is safe only as long as it stays specific.

A generic combiner hashes both ciphertexts; X-Wing omits ML-KEM's, relying on a ciphertext second-preimage property proved for ML-KEM-768 alone.Generic combiner versus X-WingGeneric combinerboth secrets, both ciphertextsAny KEM pairrobust by constructionX-Wing combineromits ML-KEM ciphertextML-KEM-768 onlyrelies on C2PRI
A generic combiner hashes both ciphertexts; X-Wing omits ML-KEM's, relying on a ciphertext second-preimage property proved for ML-KEM-768 alone.
⚠️
Efficient because specific. X-Wing's shorter combiner is proved only for ML-KEM-768 and X25519; swapping either component voids the argument that let the ciphertext be omitted.

SSH: binding by signed transcript

RFC 10042, published in August 2026, defines three hybrid key-exchange methods for SSH: ML-KEM-768 with X25519, ML-KEM-768 with P-256, and ML-KEM-1024 with P-384. The client sends its ML-KEM public key concatenated with an ephemeral elliptic-curve public key; the server checks the lengths, runs the FIPS 203 encapsulation-key check, encapsulates, and replies with the ML-KEM ciphertext, its own ephemeral elliptic-curve key, its host key and a signature over the exchange hash. OpenSSH added the X25519 method in version 9.9 in 2024 and made it the default for key agreement in version 10.0 in 2025.

The shared secret is formed by hashing the post-quantum and classical secrets together, nothing else. Binding comes instead from SSH's exchange hash, which covers both identification strings, both key-exchange initialization messages, the server's host key, the client's message containing the ML-KEM public key, the server's message containing the ciphertext, and the derived secret. Because the server signs that hash with its host key, every value of the exchange is tied to one authenticated session, the same structural move TLS makes with its transcript. ML-KEM is asked for IND-CCA-strength secrecy and correctness, and little else.

The roles are worth noticing. In a Diffie-Hellman exchange both sides contribute symmetric public values; with a KEM, the client generates the key pair and holds the decapsulation key, and the server only encapsulates. Because the client's key pair lives for one connection and is then discarded, SSH's ML-KEM methods keep the forward secrecy of an ephemeral exchange: compromising the server's long-term host key later reveals nothing about past sessions, since the host key only signs. That is the opposite of HPKE's position, where the recipient's long-term key is the decapsulation key, and it is why the two constructions place such different demands on key storage.

The RFC is precise about its remaining assumptions. It requires a fresh ephemeral key pair for both the elliptic-curve and the ML-KEM exchange on every connection and forbids reusing randomness when generating ciphertexts. It encodes both secrets as fixed-length byte strings to avoid the length-dependent hashing that enabled timing attacks such as Raccoon. And it acknowledges that an IND-CCA2 proof of the combined derivation needs the hash to behave as a random oracle, a stronger assumption for SHA-2 than it would be for SHAKE256, accepted for the sake of ubiquity.

The client sends both ephemeral public keys, the server replies with the ciphertext and signs an exchange hash covering every value, which is where binding comes from.ML-KEM hybrid key exchange in SSHSSH clientfresh keys per connectionSSH serverhost key signs the hashML-KEM public key and ECDH keyciphertext, ECDH key, signed exchange hash
The client sends both ephemeral public keys, the server replies with the ciphertext and signs an exchange hash covering every value, which is where binding comes from.

An assumptions ledger

Set side by side, the constructions divide cleanly by where binding comes from. Where a transcript is hashed and signed or authenticated, as in TLS and SSH, the KEM supplies secrecy and the protocol supplies binding, which makes those protocols tolerant of KEM substitution. Where there is no transcript, as in one-shot HPKE encryption and in any protocol that treats X-Wing as a black-box KEM, binding must come from the KEM itself, which is why both documents state their binding properties explicitly.

The ledger also records what each construction gives up. HPKE's post-quantum suites lose the authenticated mode and, like all HPKE, offer no forward secrecy against recipient compromise. X-Wing gives up generality: it is a fixed pair at a fixed security level, by design. SSH requires ephemeral keys and so gives up nothing it had, but it inherits the random-oracle assumption on SHA-2 that its RFC calls out. None of these are flaws; they are the terms on which each construction is safe, and they are the terms a reuse must respect.

One consequence deserves emphasis for anyone building crypto-agile systems. In TLS and SSH, replacing ML-KEM with another IND-CCA KEM leaves the binding argument intact. In HPKE and X-Wing it does not: HPKE would need the new KEM's own binding properties, and X-Wing's proof would have to be redone from scratch. Agility is cheap where the protocol binds and expensive where the KEM does.

What each construction takes from ML-KEM, what it supplies, and what it gives up.
ConstructionTakes from ML-KEMSupplies itselfPrivate key formGives up
TLS 1.3 hybrid groupIND-CCA secrecyTranscript hash in key scheduleEphemeral, library internalNothing for binding
HPKE with ML-KEMIND-CCA; LEAK binding of key and ciphertextKey schedule and AEAD64-byte seedAuthenticated mode; recipient forward secrecy
X-WingIND-CCA; ciphertext second-preimage resistanceSHA3-256 combiner over X25519 valuesSingle 32-byte seedGenerality: fixed components
SSH (RFC 10042)IND-CCA secrecySigned exchange hash; ephemeral keysEphemeral per connectionRelies on SHA-2 as a random oracle

Agent messaging, private inference and agent-driven shells

Agent systems meet all three constructions. Agents that exchange sealed messages, task hand-offs or tool results through a broker, rather than over a live connection, are natural HPKE users: a worker publishes a static ML-KEM key, and an orchestrator seals instructions to it. Because the post-quantum suites have no authenticated mode, the seal says nothing about who sent the instruction; for an agent about to act on a tool call, that provenance must come from a signature or a pre-shared key, decided explicitly rather than assumed. And because the worker's static key protects every message ever sealed to it, that key belongs in hardware or a managed key service, with rotation.

Model-serving endpoints meet HPKE through Oblivious HTTP, RFC 9458, which encapsulates each request to a gateway's public key and sends it through a relay, so that the relay sees who is asking but not what, and the gateway sees what but not who. Prompts and retrieved documents can stay sensitive for years, which is the harvest-now-decrypt-later case for a post-quantum suite. The gateway's single static key then becomes one of the most valuable keys in an inference platform: compromise exposes every request ever sent to it. Custom agent channels that need a hybrid KEM outside TLS are better served by X-Wing, used exactly as specified, than by a home-made concatenation of two secrets, and coding agents that operate infrastructure over SSH should verify that their client libraries negotiate the ML-KEM methods rather than silently falling back to a classical exchange.

Every one of these choices should be visible in the platform's cryptographic inventory. For each agent channel, endpoint and shell, record the construction, the suite or method actually negotiated, the private-key form and where it is stored, and whether a classical fallback occurred. The record makes post-quantum coverage measurable rather than assumed, it identifies the static keys whose compromise would expose the most history, and it turns the next algorithm transition into a query against known terms instead of a search through code.

Four questions decide whether an agent platform uses ML-KEM safely, binding, key provenance, verification scope and construction assumptions, and together they reduce to one decision procedure. First, prefer constructions that bind the transcript, and where none exists, bind public keys, ciphertexts and identities in the derivation yourself. Second, accept private keys as seeds, run the FIPS 203 checks on everything imported, and record who generated each key. Third, choose implementations whose verification claims cover the backends actually deployed, and treat binding and input checks as the platform's responsibility regardless of any badge. Fourth, use wrappers, HPKE, X-Wing or SSH, exactly within the terms their specifications state, and record those terms so that the next algorithm change is evaluated against them. Each step is small. What makes them work is writing them down.

The relay sees the agent but not the request, the gateway sees the request but not the agent, and the gateway's static ML-KEM key protects every request ever sent.Private inference over Oblivious HTTPAgent clientseals request with HPKERelaysees who, not whatGatewaystatic ML-KEM keyModel endpointsees what, not whoInference platformsealed requestforwardedopened request
The relay sees the agent but not the request, the gateway sees the request but not the agent, and the gateway's static ML-KEM key protects every request ever sent.
✅
One decision procedure. Bind in the protocol, import keys as seeds with provenance, match verification to deployed backends, and use each wrapper only on the terms its specification states.

Key takeaways

  • HPKE's ML-KEM suites store private keys as 64-byte seeds, rely on ML-KEM's leakage-strength binding, and give up the authenticated mode.
  • X-Wing omits the ML-KEM ciphertext from its combiner because ML-KEM-768 is ciphertext second-preimage resistant; the argument does not transfer to other KEMs.
  • X-Wing's single 32-byte seed supports its malicious-strength binding claim, and its draft forbids transmitting expanded keys.
  • SSH's ML-KEM methods hash only the two secrets; binding comes from the host-signed exchange hash, with ephemeral keys required on every connection.
  • Where the protocol binds the transcript, KEM substitution is cheap; where the KEM provides binding, substitution requires new proofs.
  • Agent platforms should add sender authentication to sealed messages, protect gateway keys for private inference, use X-Wing as specified, and confirm agents negotiate ML-KEM in SSH.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

✅Reusing a construction that wraps ML-KEMchecklist

Questions to answer before adopting HPKE, X-Wing or SSH ML-KEM methods in an agent system.

  • Where does binding come from: a hashed and authenticated transcript, or the KEM itself?
  • If the KEM supplies binding, which strength does the specification claim, and does your key format preserve it?
  • How is the sender authenticated, now that HPKE's post-quantum suites have no authenticated mode?
  • Which long-term key protects all past traffic, and where is it stored and rotated?
  • Is X-Wing used exactly as specified, with its 32-byte seed and without transmitting expanded keys?
  • Do agent SSH clients and servers negotiate an ML-KEM method, and is classical fallback logged?
  • Which component substitutions would invalidate the construction's proof, and are they blocked by configuration?
🚀Agent platform defaultsquickstart

Sensible starting points while the remaining drafts finalize.

  • Agent-to-agent sealed messages: HPKE with an ML-KEM-768 hybrid suite, plus a signature over each instruction.
  • Private inference requests: Oblivious HTTP with a post-quantum HPKE suite and a hardware-protected gateway key.
  • Custom channels needing a hybrid KEM: X-Wing as specified, never a home-made concatenation.
  • Infrastructure access by agents: SSH with mlkem768x25519-sha256 required, and alerts on classical fallback.

Glossary

HPKE
Hybrid Public Key Encryption, RFC 9180: a KEM, a key-derivation function and an authenticated cipher combined to encrypt to a public key.
Authenticated mode (HPKE)
A mode in which the sender authenticates through the KEM itself; not available with the post-quantum KEMs.
Hybrid KEM
A KEM that combines a classical and a post-quantum KEM so the result is secure if either component is.
KEM combiner
The function that merges the component shared secrets, and possibly ciphertexts and keys, into one hybrid secret.
X-Wing
A concrete hybrid KEM of ML-KEM-768 and X25519 with a SHA3-256 combiner and a single 32-byte private-key seed.
Ciphertext second-preimage resistance (C2PRI)
The property that nobody, even knowing the private key, can find a second ciphertext decapsulating to the same secret as a given one.
Exchange hash (SSH)
The hash over identification strings, negotiation messages, host key, exchanged key material and secret, which the server signs.
Oblivious HTTP
RFC 9458: a protocol that encapsulates requests with HPKE and routes them through a relay so no single party sees both client and content.
Forward secrecy
The property that compromising a long-term key does not expose past sessions; HPKE lacks it with respect to the recipient.
Multi-target attack
An attack that amortizes work across many keys or users; hashing the public key into key derivation separates each key's domain.

References

  1. RFC 9180, Hybrid Public Key Encryption (2022)
  2. Barnes and Connolly, Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE (draft-ietf-hpke-pq-05)
  3. Barbosa et al., X-Wing: The Hybrid KEM You've Been Looking For (IACR Communications in Cryptology 2024, ePrint 2024/039)
  4. Connolly, Schwabe and Westerbaan, X-Wing: general-purpose hybrid post-quantum KEM (draft-connolly-cfrg-xwing-kem-11)
  5. Giacon, Heuer and Poettering, KEM Combiners (PKC 2018, IACR ePrint 2018/024)
  6. RFC 10042, Post-Quantum/Traditional Hybrid Key Exchange with ML-KEM for Use in SSH (2026)
  7. RFC 9458, Oblivious HTTP (2024)
  8. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (2024)
  9. Fluhrer et al., ML-KEM Security Considerations (draft-sfluhrer-cfrg-ml-kem-security-considerations-05)