中文

Glossary

Hybrid Key Exchange (hybrid post-quantum key exchange)

Last verified

Definition

Hybrid key exchange combines a classical algorithm such as X25519 with a post-quantum KEM such as ML-KEM, so the result is secure unless both are broken.

Hybrid key exchange runs a classical and a post-quantum key establishment together and derives the session keys from both results. In TLS 1.3 each hybrid is simply a new named group: the key_share carries the concatenated classical and post-quantum values, and the two shared secrets are concatenated before entering the HKDF key schedule. Registered examples include X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024.

Why it matters

Post-quantum algorithms are young, and their cryptanalysis is less mature than that of elliptic curves. SIKE, a candidate in NIST's process, was broken in 2022 by an attack that ran on an ordinary computer. A hybrid hedges in both directions: the classical part (ECDHE) protects against an undiscovered flaw in the post-quantum algorithm or its implementation, and the ML-KEM part protects against a future quantum computer. The costs are larger handshake messages, over a kilobyte extra, and a small amount of extra computation.

Example

An illustrative TLS 1.3 negotiation with a hybrid group:

ClientHello
  supported_groups: X25519MLKEM768, X25519, secp256r1
  key_share:        X25519MLKEM768 (1,216 bytes), X25519 (32 bytes)
ServerHello
  key_share:        X25519MLKEM768 (1,120 bytes)
shared secret = ML-KEM-768 secret || X25519 secret -> TLS 1.3 key schedule

Common misconceptions

  • "Hybrid is weaker than pure post-quantum." It is designed so that an attacker must break both components; it is at least as strong as the stronger one.
  • "Hybrid key exchange also makes certificates post-quantum." It covers only key establishment; signatures are a separate migration.
  • "Turning it on is a flag day." Clients offer hybrid and classical groups side by side, and servers without hybrid support keep negotiating X25519 or P-256.

See also