Skip to content

Build1 publisher2 min readPublished

Hybrid ML-KEM key exchange adds about 1,600 bytes to every fresh TLS handshake

AWS and Microsoft are already shipping ML-KEM hybrid groups, so the question for platform teams is whether the old proxy, SDK and appliance in the path still complete a handshake that got bigger.

The Engineer · Build desk

Illustration accompanying Hybrid ML-KEM key exchange adds about 1,600 bytes to every fresh TLS handshake

What happened

  • AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM and Secrets Manager, and Microsoft has started shipping Windows platform support for the hybrid TLS groups.
  • The first wave covers key exchange only, pairing classical elliptic-curve key exchange with ML-KEM, and current platform docs name the combined group X25519MLKEM768.
  • Measurement work in 2026 found the internet migrating unevenly, with banking and government still carrying a lot of older TLS behaviour.
  • Hybrid ML-KEM covers session confidentiality against recorded traffic being decrypted later, while certificates and signatures are a separate post-quantum migration.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint The tolerance test lands on equipment platform teams often do not own: an inspection proxy or TLS-terminating appliance can reject a handshake that both client and server support, and a vendor throughput benchmark will never surface it.
  • decision Fallback has to become a switch someone chooses. The negotiated group belongs in telemetry before the default flips.
  • cost The extra bytes are billed by connection pattern, so the services that pay are the ones opening fresh handshakes per request instead of pooling them.
  • exposure If the 2026 measurements hold, the sectors slowest to adopt hybrid key exchange are banking and government, so traffic recorded there today stays exposed to later decryption the longest.

A hybrid group runs both key exchanges at once. The connection combines classical elliptic-curve key exchange with ML-KEM, and the session key keeps the property teams care about as long as one half of the pair holds [7]. ML-KEM is the NIST-standardised key encapsulation mechanism that came out of the Kyber line [6]. Getting that into production needs clients to offer the right groups, servers to select them, and middleboxes to not fall over when they see them [8]. Cloudflare's documentation covers the client-to-edge leg and the edge-to-origin leg, so a CDN estate has two negotiations to verify [2]. The IETF TLS work is still moving [4].

AWS's KMS benchmark put the extra handshake at about 1,600 bytes plus a small amount of compute [9]. A service that reuses no connections therefore carries roughly 1.6 MB of additional handshake bytes per thousand requests [1]. With normal TLS connection reuse, AWS measured the effect on KMS request throughput as basically noise [10]. In a worst-case setup that forced a fresh handshake for every request, the average throughput drop was described as still modest, without a percentage attached [11].

Those numbers describe KMS traffic on AWS's own clients. They transfer to your service if its connection reuse rate is similar, if its client library negotiates the hybrid group at all, and if nothing between the two ends rewrites or inspects the handshake. The average does not cover the estate, by the post's own list: whether a Java service is on the AWS CRT HTTP client or an older path, whether a service mesh strips or blocks something, and whether the compliance proxy, payment provider integration or TLS-terminating appliance in the path behaves [12]. "The math can be ready before your estate is," pvgomes wrote on dev.to [14].

In my view the first test worth running is against the oldest client in the path. Whatever you test first, the negotiated group has to be visible in telemetry and rollback has to be an explicit control, because, as pvgomes put it, "it fell back to classical TLS somewhere" is not the same as "we understand production" [13].

What to watch

  • Whether AWS, Cloudflare or Microsoft move ML-KEM hybrid groups from supported to preferred by default, and in which SDK versions.
  • A follow-up to the 2026 measurement work showing whether banking and government TLS behaviour has changed.
  • Vendor documentation for post-quantum authentication, which the source treats as a migration separate from key exchange.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories