Hybrid key exchange
Combining a classical and a post-quantum key exchange so the session key stays secure unless both are broken.
A hybrid key exchange runs a classical algorithm (usually X25519) and a post-quantum KEM (ML-KEM-768) together and feeds both shared secrets into the key schedule. If ML-KEM turns out to have a flaw, X25519 still protects today's traffic; if a quantum computer breaks X25519, ML-KEM still does.
In TLS 1.3 this is the X25519MLKEM768 named group. Chrome, Firefox, Cloudflare and major CDNs enabled it by default from late 2024 onwards, so a large share of web traffic already uses it. OpenSSH defaults to mlkem768x25519-sha256 from release 10.0.
Deployment problems are mostly size: the client key share grows to about 1.2 KB, pushing the ClientHello past one packet, which broke some middleboxes and servers that assumed it fit. Interview answers should mention why hybrid rather than pure post-quantum (confidence in new maths is low) and that it addresses harvest-now-decrypt-later.