Skip to content

CONCEPT Cited by 2 sources

Hybrid key encapsulation

Definition

Hybrid key encapsulation is a key-agreement construction where two independent KEMs run in parallel and the resulting session key is derived from both of their shared secrets combined. The critical property: the composite is at least as strong as the stronger of the two KEMs. Break one and the other still protects the session.

Canonical transition-era shape:

PQ-KEM   shared secret  s_pq
Classical shared secret  s_cl
session_key = KDF(s_pq || s_cl || handshake_transcript)

Where KDF is a cryptographic hash (SHA-512 in SSH's sntrup761x25519-sha512 instance — the trailing -sha512 names the KDF). Both shared secrets must be compromised for the session key to be compromised. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

Why hybrid, not PQ-only

During the PQ transition window, hybrid is strictly safer than PQ-only for two distinct reasons:

  1. PQ primitive immaturity. PQ KEMs like Streamlined NTRU Prime and ML-KEM (Kyber) have far less cryptanalytic scrutiny than decades-old ECDH. If a CRQC-independent classical attack is later found against the PQ primitive, the hybrid is still classically strong.
  2. Classical primitive unaffected by PQ rollout. ECDH-X25519 has battle-tested security against classical attackers. Hybrid retains that baseline for free — the classical half costs ~32 bytes of key and ~µs of CPU on modern hardware, a rounding error next to the PQ half's 1–2 kB and tens-of-µs.

"Even though these post-quantum algorithms are newer and thus have received less testing, combining them with the classical algorithm ensures that security won't be weaker than what the classical algorithm provides." (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

The cost is ~1 kB more on the wire per handshake and a modest CPU bump. For almost any deployment outside ultra-high-fanout / ultra-latency-sensitive environments, this is the right trade.

Canonical instances

  • SSH: sntrup761x25519-sha512 (formerly sntrup761x25519-sha512@openssh.com) = Streamlined NTRU Prime sntrup761 + X25519 ECDH, combined with SHA-512. Default KEX in OpenSSH 9.0+ (2022-04). Rolled out to github.com SSH endpoints 2025-09-17. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
  • TLS: X25519MLKEM768 = X25519 + ML-KEM-768, combined with HKDF-Expand. Negotiated in TLS 1.3 via the key_share / supported_groups extensions. Widely deployed by browsers and CDNs since 2024 (initially as X25519Kyber768Draft00).
  • Pattern: the two-KEM-plus-KDF shape is the dominant hybrid composition across protocols. Alternatives (XOR, single-KDF-of-one) are generally discouraged — the concatenation into a collision- resistant KDF provides the "stronger of the two" property cleanly.

Not to be confused with

  • Hybrid encryption (asymmetric-encrypts-symmetric-key) — a classical primitive where one KEM's output is used as a symmetric key. Uses a single KEM, not two.
  • Hybrid public-key signatures — signing with both classical and PQ signatures side-by-side. Separate construction (for signatures), same motivating logic.
  • TLS cross-signed certificates (concepts/cross-signed-certificate-trust) — a trust-chain technique, unrelated to session-key derivation.

Trade-offs

  • Wire overhead: PQ public keys and ciphertexts are ~30–40× larger than X25519. Hybrid carries both, so a handshake that was ~100 bytes per side becomes ~1.2 kB per side. Under MTU constraints (e.g. TLS ClientHello split across multiple packets), this can interact unfavorably with middleboxes.
  • CPU cost: both primitives run; the PQ side dominates. Typically still <1 ms per handshake on modern x86; may matter at very high connection rates (CDN edge, SSH bastions).
  • Algorithm name baggage: the composite gets its own wire-level name (sntrup761x25519-sha512) for negotiation. Early deployments used vendor-namespaced names (@openssh.com suffix); later promoted to standard names.
  • Not a permanent answer. Once PQ primitives are sufficiently mature AND FIPS-compliant versions are deployed, protocols will likely eventually deprecate the classical halves. Hybrid is a transition-era construction.

FIPS constraint

In FIPS-regulated environments the full hybrid is usually not acceptable unless both halves are FIPS-approved. X25519 was added to FIPS 186-5 in 2023; ML-KEM was approved in FIPS 203 in 2024; Streamlined NTRU Prime is not FIPS-approved. This means GitHub's sntrup761x25519-sha512 cannot be enabled in the US-region GHEC (concepts/fips-cryptographic-boundary) even though X25519 alone is FIPS-approved — the negotiated algorithm is a single FIPS entry, not a product of two. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

GitHub signals a future migration once OpenSSH (or the SSH library they use) ships ML-KEM-based hybrid KEX: "As the SSH libraries we use begin to support additional post-quantum algorithms, including ones that comply with FIPS, we'll update you on our offerings."

Seen in

Last updated · 200 distilled / 1,178 read