Skip to content

ETSI TS 103 744 Alignment — Quantum-safe Hybrid Key Establishment

This page describes how the platform's composite KEM keys (COMPOSITE_KEM_COMBINE) implement the hybrid key combiners of ETSI TS 103 744, and how their design corresponds to the deployment considerations of ETSI TR 103 966. Each statement names the clause it corresponds to and the component that implements it.

Documents and versions

Document Version used Primary source (checked 2026-10-04)
ETSI TS 103 744, CYBER; Quantum-Safe Cryptography (QSC); Quantum-safe Hybrid Key Establishment V1.2.2 (2026-02), the latest publication ETSI deliver directory, TS 103 744
ETSI TR 103 966, CYBER; QSC; Deployment Considerations for Hybrid Schemes V1.1.1 (2024-10), the only publication ETSI deliver directory, TR 103 966

TS 103 744 is the normative document for the combiners. TR 103 966 is informative. TS 103 744 specifies key establishment, so this page covers composite KEM keys; composite signatures are described on IETF Composite ML-KEM and Composite Signatures — Alignment.

Scope

A composite KEM key pairs one classical elliptic-curve component with one post-quantum KEM component. The content-encryption key (CEK) of every JWE produced with the key is derived by one of five KDF tokens, chosen when the key is created and recorded with its key material:

KDF token Construction
CatKDF TS 103 744 clause 8.2.3, concatenate hybrid key combiner, instantiated with HKDF
CasKDF TS 103 744 clause 8.3.3, cascade hybrid key combiner, instantiated with HKDF and an HMAC PRF
HKDF-SHA256 (default), HKDF-SHA384, HKDF-SHA512 The NIST SP 800-227 key combiner in HKDF form

The two ETSI combiners are implemented in core-api by CatKdf and CasKdf, selected through KeyCombinerRegistry (CatKdfCombiner, CasKdfCombiner); the token vocabulary is KdfAlgorithm in common-algorithms.

TS 103 744 clause 7 — cryptographic primitives

Clause What the platform does
7.2.3 Concatenate-and-hash-based context formatting function cahb_f builds the CatKDF context and each CasKDF round input (CombinerFraming.cahbF)
7.3.2 PRF to HMAC mapping Each CasKDF round PRF is HMAC over the hash of the pairing
7.4.2 KDF to HKDF mapping HKDF with an absent label taken as digest_len zero octets of salt (Hkdf, CatKdf, CasKdf)
7.5.2 Elliptic curve domain parameters The classical component runs on P-256, P-384, brainpoolP256r1, brainpoolP384r1, X25519 or X448 — every curve 7.5.2 lists — as an ECDH-KEM with a fresh ephemeral key for each encapsulation. An X25519 or X448 agreement whose output is all-zero is refused (RFC 7748 §6.1)
7.6.2 Post-quantum KEMs The post-quantum component is ML-KEM-512, ML-KEM-768 or ML-KEM-1024 (FIPS 203), the KEM this clause approves, through the JCA javax.crypto.KEM interface
7.7.2 Parameter sets Ten of the curve/ML-KEM pairs §7.7.2 enumerates, with the HKDF KDF (listed below)

The ten pairs, and the hash each runs with under CatKDF and CasKDF:

Hash (§7.7.2 parameter set prefix) Pairs in the catalogue
SHA-256 (HKDFwSHA256_…) X25519 + ML-KEM-512, X25519 + ML-KEM-768, P-256 + ML-KEM-512, P-256 + ML-KEM-768, brainpoolP256r1 + ML-KEM-768
SHA-384 (HKDFwSHA384_…) X448 + ML-KEM-768, X448 + ML-KEM-1024, P-384 + ML-KEM-768, P-384 + ML-KEM-1024, brainpoolP384r1 + ML-KEM-1024

The hash is chosen by KdfAlgorithm.hashFor: SHA-256 for a Level 1 pairing and SHA-384 for a Level 3 or Level 5 pairing, which reproduces the §7.7.2 hash on each of the ten pairs. These ten pairs carry the ETSI attribution in the catalogue (CompositeAlgorithmCatalogue), so a policy that requires ETSI admits them.

TS 103 744 clause 8 — hybrid key establishment

Clause What the platform does
8.1.2 Key establishment abstraction to ECDHE, 8.1.3 Key establishment abstraction to KEM Each component is used as a KEM, (k, C) = Encaps(P). The classical ciphertext is the ephemeral public key (SEC 1 uncompressed point, or the RFC 7748 u-coordinate) and travels as that component's encrypted_key (KemOperations, CompositeJweCoreEncryptor)
8.2.3 Concatenate hybrid key combiner - CatKDF secret = k1 ‖ k2 with the classical secret first, context = cahb_f(info, MA, MB), key_material = HKDF(secret, label, context, length) (CatKdf.derive)
8.3.3 Cascade hybrid key combiner - CasKDF One HMAC round per component, each followed by HKDF; the key material of the second round is the CEK (CasKdf.derive)
Annex B.1 Security definitions CatKDF is IND-CCA secure in the random-oracle model when at least one component is OW-CCA; CatKDF and CasKDF are IND-CPA secure when at least one component is OW-CPA. Both are offered, and the key's KDF token states which construction it uses

Known-answer vectors

CatKdf and CasKdf reproduce the four HKDF-SHA256 known-answer vectors ETSI printed in TS 103 744 V1.2.1 Annex D.2.1, D.2.4, D.3.1 and D.3.4 — P-256 + ML-KEM-768 and X25519 + ML-KEM-768, each under CatKDF and under CasKDF (core-api CatKdfKnownAnswerTest, CasKdfKnownAnswerTest). In V1.2.2, Annex D.1 "Test Vectors Repository" points to ETSI's forge repository (103744_QHKEX, tag kats_v1.2.x) for the vectors. Clauses 7 and 8 carry the same numbers and constructions in V1.2.1 and V1.2.2.

Additions the platform makes on top of clause 8

These are the platform's own design, used with every KDF token:

  • The KDF token is carried as anka_kdf in the JWE protected header, which is the AES-256-GCM additional authenticated data. A token that differs from the KDF recorded with the key material is refused with 422 (CompositeJweAdmission, CompositeKdfMismatchException).
  • A domain separator, frame("ankasecure:composite-kem", alg, kdfToken), binds the pairing and the KDF token into every derivation (CombinerInput).
  • Both component ciphertexts and both component public keys enter the derivation, so a substituted component ciphertext produces a different CEK and the AES-GCM tag check refuses the message with 422 (CompositeJweCoreDecryptor).
  • The concatenated secret, each context and each intermediate round value are wiped in finally blocks; nothing derived is logged.

TR 103 966 — deployment considerations

Clause What the platform does
5.1 Hybrid security The CEK is derived from both shared secrets and both ciphertexts, so confidentiality holds while either component holds. Only the two KEM ciphertexts travel with the message
7.1.1 Number of components Every composite key has exactly two components: one traditional, one post-quantum (CompositeAlgorithmProfile)
7.1.2 Choice of components ML-KEM-768 and ML-KEM-1024 are offered with P-256, P-384, P-521, X25519, X448 and the Brainpool curves, which matches the clause's example of hedging ML-KEM with larger parameter sets
7.3 Migration and forwards compatibility Ciphertext moves between keys and between pairings by re-encryption (POST /api/v3/crypto/reencrypt, and POST /api/v3/crypto/stream/reencrypt for streams). Rotation creates a new material version under the same kid; a protected-header ank_kv names the version that decrypts, and its absence selects the primary version
A.3.3 Concatenation with full KDF Every KDF token binds both shared secrets, both ciphertexts, both public keys and the domain separator

Catalogue facts

  • 27 COMPOSITE_KEM_COMBINE pairings: 15 with ML-KEM and 12 with HQC (CompositeAlgorithmCatalogue).
  • The 15 ML-KEM pairings include the ten §7.7.2 pairs above and five more: X448 + ML-KEM-512, P-384 + ML-KEM-512, P-521 + ML-KEM-768, P-521 + ML-KEM-1024 and brainpoolP512r1 + ML-KEM-1024.
  • The HQC pairings are the platform's code-based alternative to lattice-based ML-KEM (NIST selected HQC for standardization in March 2025). They use the same five KDF tokens and the same JWE shape. TS 103 744 clause 7.6.2 approves ML-KEM, so the alignment described on this page is the ML-KEM pairs'.
  • JWE shape (RFC 7516 §7.2.1, General JSON serialization): the protected header carries enc, kid, anka_kdf, ank_kv when the material version is pinned, and optionally typ; each of the two recipients carries header.alg naming its component and encrypted_key holding that component's encapsulation; there is no shared unprotected header. The streaming form adds one root member, anka_composite_mode.

The full pairing matrix is on the Composite Algorithms Catalog.

References

  • ETSI TS 103 744 V1.2.2 (2026-02), Quantum-safe Hybrid Key Establishment — PDF
  • ETSI TR 103 966 V1.1.1 (2024-10), Deployment Considerations for Hybrid Schemes — PDF
  • NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms (September 2025)
  • NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  • RFC 5869 (HKDF), RFC 7516 (JWE), RFC 7748 (X25519 and X448)
  • IETF Composite ML-KEM and Composite Signatures — Alignment
  • Compliance Packs