ETSI publishes TS 103 744 v1.2.1: Hybrid key establishment for the quantum transition

Sophia Antipolis, March 2025 – ETSI’s Technical Committee CYBER has released ETSI TS 103 744 V1.2.1, a technical specification for quantum‑safe hybrid key establishment—methods that combine classical elliptic‑curve Diffie‑Hellman (ECDH) with post‑quantum key encapsulation (ML‑KEM) to derive shared keys that remain secure even if one component is later broken. The new version codifies two combiner constructions, enumerates fixed parameter sets, and ships with test vectors and a reference implementation to speed adoption.

What’s in the document (at a glance)

• Purpose and scope. The spec defines how to derive cryptographic keys from multiple shared secrets – one from a traditional scheme (ECDH) and one from a quantum‑safe KEM – so that the resulting hybrid remains secure if either side remains secure. It explicitly targets deployments that need to move ahead of full assurance in post‑quantum primitives.
• Two hybrid combiners.
  • Concatenate combiner (CatKDF): derive keys from the concatenation of secrets and context; defined for both ephemeral and static keying variants.
  • Cascade combiner (CasKDF): inject secrets in sequence (a “chain secret” plus round‑by‑round KDF); also defined in ephemeral and static forms.
• Algorithms allowed.
  • Hashes: SHA‑256, SHA‑384.
  • PRFs: HMAC (with SHA‑2) and KMAC128/256.
  • KDFs: HKDF; NIST SP 800‑56C one‑step KDF using HMAC; and KDF using KMAC, with precise mappings.
  • Classical key exchange: ECDH over NIST P‑256/P‑384, brainpoolP256r1/brainpoolP384r1, X25519, and X448.
  • Post‑quantum KEM: ML‑KEM (FIPS 203), at security levels 512/768/1024.
• Fixed parameter sets. The spec lists interoperable, named ciphersuite triples that bind a KDF family/strength to a specific ECC curve and ML‑KEM level.
• Protocol abstraction and message flow. A clean abstraction (Initiator A ↔ Responder B, messages MA/MB) is provided; the diagram on p.10 shows message sequencing and the transcript concept that feeds the KDF context. The spec stresses that messages must be authenticated (e.g., signatures, certificates).
• Security properties. In the random‑oracle model, the combiners achieve IND‑CPA if at least one underlying scheme is OW‑CPA; for static‑key use cases, CatKDF attains IND‑CCA if at least one component is OW‑CCA. The document prudently frames these as hybrid KEMs and avoids broader AKE claims.
• Interoperability aids. Annexes define a message formatting function for test‑vector generation and provide comprehensive test vectors across CatKDF/CasKDF and multiple parameter sets, plus a C reference implementation (with build notes: OpenSSL 3.2.4‑dev, LibOQS 0.11.0‑release, OQS‑Provider 0.7.0‑release).
• Maturity and change history. The change log tracks the tightening of algorithm choices (e.g., restriction to ML‑KEM), additions of KMAC/HMAC‑KDF mappings, and consistency edits leading up to this March 2025 publication.

Why this matters (key benefits for implementers and risk owners)

1. Defense‑in‑depth during migration. By construction, a CatKDF/CasKDF session key survives the failure of either the classical or post‑quantum component—critical while PQC assurance is still accumulating. This directly addresses “harvest‑now, decrypt‑later” risk without waiting on full PQC‑only deployments.
2. Interoperable profiles, fewer decisions. Fixed parameter sets eliminate guesswork and mis‑matches (e.g., pairing SHA‑384/KMAC‑256 with P‑384/ML‑KEM‑1024 where appropriate), reducing integration friction across vendors and sectors.
3. Clear security conditions. The document states what security notions are achieved (IND‑CPA/IND‑CCA) and under which assumptions (OW‑CPA/OW‑CCA of components), helping architects do proper threat mapping and avoid over‑claiming.
4. Implementation guidance baked in. The protocol abstraction, message context handling, and a requirement to authenticate transcripts cut down on common pitfalls in bespoke hybrids. The examples and figures make the handshake choreography concrete.
5. Testability from day one. The test vectors and a non‑production reference speed conformance testing and continuous integration. Teams can validate their KDF/context wiring and parameter choices before tackling full protocol integration (TLS, QUIC, SSH, IPSec).
6. Practical flexibility. Support for modern curves (X25519/X448) alongside NIST/brainpool and for multiple KDF families (HKDF, HMAC one‑step, KMAC) lets implementers meet platform constraints while staying within a standard envelope.

Opinion – Why TS 103 744 V1.2.1 is an important step for quantum readiness

Standards set the center of gravity. By pinning hybrids to ML‑KEM (FIPS 203) and a finite set of ECC curves/KDFs, ETSI reduces the “combinatorial explosion” that has hampered cross‑vendor trials. This is essential for procurement and cross‑domain deployments where interoperability and auditability trump bespoke “best‑effort” engineering.

A pragmatic bridge, not the destination. The spec deliberately avoids claiming a full authenticated key‑exchange (AKE) security theorem; it frames the constructions as hybrid KEMs with explicit IND‑CPA/IND‑CCA conditions. That realism is welcome: real‑world protocols still need robust authentication, transcript binding, and channel security layered in (e.g., via TLS 1.3 or domain‑specific control planes). In short, this document gives you the hybrid core; you must integrate it into a sound end‑to‑end protocol.

Operational clarity matters. The emphasis on message authentication, labels, and context formatting avoids subtle but serious cross‑protocol key‑reuse and parsing issues. For organizations building long‑lived systems, the guidance on label construction and on cb_f / cahb_f context functions will pay dividends in future audits and crypto‑agility exercises.

Where to start if you’re planning pilots. For most environments, begin with X25519 + ML‑KEM‑768 using HKDF‑SHA‑256 (CatKDF) as a balanced default; move to P‑384/X448 + ML‑KEM‑1024 with SHA‑384/KMAC‑256 where higher margins or FIPS alignment is required. Use the Annex D test vectors to lock down byte‑exact KDF outputs, and confirm handshake transcript coverage with the Figure 2/4/6 patterns before you wire this into TLS or QUIC.

Caveats. The specification presently restricts PQ KEMs to ML‑KEM. That stabilizes deployments but may limit jurisdictions or use cases exploring alternative finalists/contenders; watch for future revisions as the PQC landscape evolves. Also, static‑key use requires the stronger IND‑CCA condition—ensure your component choices and configuration actually meet it.

Bottom line

ETSI TS 103 744 V1.2.1 gives vendors and operators a clear, testable, and interoperable path to deploy hybrid key establishment today – so you can meaningfully reduce quantum risk while standards and assurance for pure‑PQC deployments continue to mature. For organizations building quantum‑resilient roadmaps, this is a near‑term implement item, not a “wait‑and‑see.”