TLS 1.3 Hybrid Key Exchange using X25519Kyber768 / ML-KEM
Over the last few months, we've seen a fair bit of action in the industry relating to Post-Quantum Cryptography: NIST at long last standardized the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), and browsers and cloud providers started rolling out hybrid key exchange in TLS 1.3 (primarily1 using X25519 with Kyber768). Having had to wrap my head around what that TLS 1.3 hybrid key exchange handshake actually looks like in practice, I figured I'd share my explanation here as well:
For the most part, we're following the standard TLS 1.3 connection flow. What's different here is what keys are generated and how they're used, so let's focus on that:
Yeah, there's a lot going on there. The good thing is that this is pretty much the same for ML-KEM in all its variations (e.g., X25519Kyber768Draft00, X25519MLKEM768, or SecP256r1MLKEM7682). But let's put this in words:
We begin with key generation on the client side. Here, the client generates a KEM public /private key pair as well as an X25519 public /private key pair. The client also generates a standalone X25519 public /private key pair as a failover in case the server doesn't speak X25519Kyber768Draft00 / X25519MLKEM768. If the server speaks X25519Kyber768Draft00 / X25519MLKEM768, then this key isn't used at all -- we generated and sent it for nothing, hooray!
