# ETSI TS 103 744: Hybrid Key Exchange Profile **Source**: https://quantumsequrity.com/blog/etsi-ts-103-744 **Category**: Standards & Documents --- [← Back to Blog](../../blog.html) Standards & Documents # ETSI TS 103 744: Hybrid Key Exchange Profile 11 min read The cryptographic community has converged on hybrid mode as the right approach for the post-quantum transition: combine a classical algorithm (X25519, P-256) with a post-quantum algorithm (ML-KEM, HQC) so security holds if either one is broken. The principle is clear. The details, less so. How exactly do you combine two shared secrets? Which key derivation function? What context binding? Which order? Get the combiner wrong and you can lose the security properties you tried to gain. ETSI Technical Specification TS 103 744 addresses this. It is a normative specification for hybrid key exchange profiles, published by ETSI Cyber Working Group. The document provides concrete combiner constructions, parameter sets, and negotiation patterns. It is referenced by IETF drafts and serves as the European baseline for hybrid PQC deployment. This post walks through what TS 103 744 specifies, how the combiners work, and how QNSQY's hybrid implementation aligns with the standard. For anyone implementing hybrid PQC in TLS, IPsec, S/MIME, or proprietary protocols, TS 103 744 is the reference for getting the combiner right. ## What Hybrid KEX Means A key encapsulation mechanism (KEM) like ML-KEM lets two parties establish a shared secret. Alice has a key pair. Bob takes Alice's public key, runs encapsulation, gets back a shared secret and a ciphertext. Bob sends the ciphertext to Alice. Alice runs decapsulation with her secret key and the ciphertext, recovers the same shared secret. Hybrid KEX runs two KEMs in parallel: - Classical KEM: typically X25519 or ECDH over P-256 - Post-quantum KEM: ML-KEM or HQC Each produces a shared secret. The two are combined into a single hybrid shared secret. The hybrid is secure if either component is secure. An attacker breaking only the classical KEM does not learn the hybrid secret; same for the PQC KEM. The combiner is the function that takes the two shared secrets and produces the hybrid one. Getting it right is what TS 103 744 addresses. ## The Combiner TS 103 744 specifies a KDF-based combiner. The basic pattern: ``` hybrid_secret = KDF(classical_secret || pqc_secret, context_info) ``` Specifically: - KDF is HKDF (Hash-based KDF, IETF RFC 5869) - Hash is SHA-256, SHA-384, or SHA-512 depending on security level - context_info binds the combiner to specific protocol context: which algorithms, transcripts, identifiers - The result is the hybrid shared secret used for key derivation Why HKDF? It is a standard, well-analyzed, available in every cryptographic library, and handles arbitrary input lengths cleanly via the extract-then-expand pattern. It is the same KDF used in TLS 1.3 and most modern protocols. Why context binding? Without it, a man-in-the-middle could use the same hybrid secret in different contexts, leading to confusion attacks. The context info typically includes: KEM identifiers, group/curve identifiers, transcript hash, protocol identifier. ## The Concatenation Order TS 103 744 requires a specific concatenation order: classical first, then PQC. This is consistent with IETF drafts and matters for interoperability. If two implementations disagree on the order, they will compute different shared secrets and the handshake will fail. ``` input = classical_shared_secret || pqc_shared_secret hybrid_secret = HKDF(input, context_info) ``` Length matters too. Classical X25519 produces 32 bytes; ML-KEM produces 32 bytes (Cat 1, 3, 5 all output 32 bytes for the shared secret part). The concatenated input is 64 bytes for typical hybrid pairs. ## Why Not XOR? Some early hybrid proposals used XOR as the combiner: `hybrid = classical XOR pqc`. TS 103 744 (and IETF guidance) rejects this for general use. The reason: XOR only preserves security if both inputs have full entropy. If one of the KEM secrets has reduced entropy (due to a partial break or implementation flaw), XOR can leak information. HKDF is robust against partial entropy in either input because the hash function washes out any structure. The cryptographic literature has formal proofs for the HKDF combiner under different attack models, including the Bindel-Brendel-Fischlin-Goncalves-Stebila construction that shows hybrid PRF-based combiners preserve IND-CCA security if either component is IND-CCA. ## Context Binding The `context_info` parameter to HKDF is critical. TS 103 744 specifies what to include: - **Protocol identifier**: a unique label for the protocol context (e.g., "TLS 1.3 hybrid KEX") - **Algorithm identifiers**: which classical KEM, which PQC KEM - **Group / curve identifiers**: for the classical KEM specifically - **Transcript hash**: hash of all handshake messages so far (in protocols that have them) Without proper context binding, an attacker could: - Replay shared secrets across protocols - Confuse parties about which algorithms were negotiated - Mount a downgrade attack to weaken one component Including the context info in the HKDF call binds the hybrid secret to the specific session and prevents these attacks. ## Parameter Sets TS 103 744 defines parameter sets matching common security levels: ### Hybrid Cat 1 (around AES-128 quantum-resistant) - Classical: X25519 - PQC: ML-KEM-512 - Hash: SHA-256 ### Hybrid Cat 3 (around AES-192 quantum-resistant) - Classical: P-384 or X448 - PQC: ML-KEM-768 - Hash: SHA-384 ### Hybrid Cat 5 (around AES-256 quantum-resistant) - Classical: P-521 or X448 - PQC: ML-KEM-1024 - Hash: SHA-512 QNSQY uses similar parameters: X25519 + ML-KEM-512/768/1024 with SHA-256-derived keys. The hash for HKDF is SHA-256, with security level driven by the KEM choice. ## Hybrid Negotiation Beyond the combiner, TS 103 744 covers negotiation. In a real protocol like TLS, both endpoints need to agree on which hybrid combination to use. TS 103 744 follows the pattern of IETF TLS named groups extended to hybrid: - Each hybrid combination gets a code point - Client offers a list of acceptable hybrid groups - Server picks one and signals the choice - Both parties use the selected hybrid combiner Specific TLS hybrid named groups (numbers TBD by IANA): - secp256r1_mlkem512 - x25519_mlkem512 - secp384r1_mlkem768 - x448_mlkem768 - secp521r1_mlkem1024 These code points let endpoints negotiate hybrid mode without protocol changes beyond the named group registry. ## Implementation Pitfalls TS 103 744 (and the IETF drafts that mirror it) flag several pitfalls: ### Concatenation order mismatch If two implementations use different concatenation orders, they will compute different shared secrets and fail to interoperate. TS 103 744 fixes this: classical first, then PQC. ### Context info inconsistency If both endpoints don't agree on the context_info bytes, they will compute different secrets. This is more subtle than concatenation order because context_info has many fields. ### Length truncation If the hybrid secret is truncated to derive session keys, both endpoints must agree on the truncation length. TS 103 744 specifies output lengths matching the security level. ### Reusing shared secrets The hybrid secret should be used in HKDF derivation, not directly as a session key. Direct use can leak structure or correlate with attacker observations. QNSQY's implementation handles all these by using a single, well-tested hybrid combiner function that accepts the two KEM outputs and a fixed context label, producing a 32-byte file encryption key via HKDF-SHA-256. ## How TS 103 744 Aligns with IETF The IETF has its own drafts for hybrid KEX. The most relevant is `draft-ietf-tls-hybrid-design` for TLS 1.3 hybrid KEX. This draft uses the same combiner pattern as TS 103 744: HKDF over the concatenation, with TLS-specific context info. ETSI TS 103 744 was published in December 2020, before the IETF drafts converged. The two now align technically. ETSI provides the European industry view; IETF provides the protocol-specific definitions. Implementations following one will be compatible with the other. For QNSQY, this means following IETF and TS 103 744 conventions both gives a single implementation that works across European, US, and global deployments. See [IETF PQUIP drafts](../ietf-pquip-drafts.html). ## Hybrid Beyond TLS TS 103 744's combiner pattern applies to other protocols too: - **IPsec / IKEv2**: hybrid KEX in the IKE_SA_INIT exchange - **SSH**: hybrid as a new key exchange method - **S/MIME / CMS**: hybrid public key encryption for email - **WireGuard**: research drafts for hybrid noise protocol modifications - **Application-layer**: file encryption, key escrow, custom protocols QNSQY is in the application-layer category. The QSPG v2 file format uses TS 103 744-aligned hybrid: ML-KEM ciphertext and X25519 ephemeral are stored in the file header, both shared secrets are derived on decryption, the hybrid combiner produces the file encryption key. See [hybrid encryption](../hybrid-encryption.html). ## Cryptographic Agility TS 103 744 supports cryptographic agility by separating the combiner pattern from the algorithm choices. New PQC algorithms (HQC when standardized in FIPS 209, future schemes) plug into the same combiner. Only the algorithm identifiers in `context_info` need updating. This is essential for the long term. PQC algorithms today are ML-KEM and HQC. In 2030 or 2040, new algorithms may emerge. The combiner pattern remains valid; the algorithms slot in. ## Triple-Hybrid Constructions A growing line of research investigates triple-hybrid combiners that mix three independent KEMs: classical (X25519), lattice (ML-KEM), and code (HQC or Classic McEliece). The motivation is mathematical diversification: if a structural weakness is found in lattice cryptography, the code-based component still provides quantum resistance, and vice versa. ETSI TS 103 744 v1.1.1 focuses on dual hybrid, but the same KDF-based combiner pattern extends naturally: HKDF over `secret_a || secret_b || secret_c` produces a hybrid secret secure if any one component holds. The cost of triple-hybrid is bandwidth. Three KEMs mean three ciphertexts in the handshake. ML-KEM-1024 ciphertext is 1568 bytes, HQC-256 ciphertext is 14421 bytes, X25519 ephemeral is 32 bytes. Total: about 16 KB per handshake. For TLS this is acceptable on broadband but heavy on cellular or satellite. For application-layer file encryption (where the handshake happens once per file), the cost is amortized over the encrypted payload. QNSQY's Business tier is positioned to support triple-hybrid in a future release: X25519 plus ML-KEM-1024 plus HQC-256. The combiner would still be HKDF-SHA-256, the context info would include all three algorithm identifiers, and the file format already reserves space in QSPG v2 headers for additional KEM slots. This aligns with the IR 8528 guidance to keep HQC ready as a non-lattice diversification path. ## Alignment with NSA CNSA 2.0 The NSA's Commercial National Security Algorithm Suite 2.0, published in September 2022, mandates ML-KEM-1024 and ML-DSA-87 for National Security Systems by 2033. CNSA 2.0 does not explicitly require hybrid mode, but most US national security customers are deploying hybrid during the 2025 to 2030 transition window. ETSI TS 103 744 provides the European industry equivalent: hybrid X25519 plus ML-KEM-1024 satisfies both CNSA 2.0 (through the ML-KEM component) and TS 103 744 (through the documented combiner). QNSQY's Business tier configuration of X25519 plus ML-KEM-1024 with HKDF-SHA-256 sits in this overlap, making the same binary acceptable to both regulatory frameworks without a configuration change. ## FAQ ### Is the TS 103 744 combiner the same as IETF's? Yes. The HKDF-based concatenation combiner is the same in both. ETSI published first; IETF drafts converged on the same pattern. They are interoperable. ### Why HKDF specifically? HKDF is the modern KDF of choice. It is in every cryptographic library, well-analyzed, supports arbitrary input and output lengths, and handles non-uniform inputs cleanly. NIST SP 800-56C Rev 2 and IETF RFC 5869 both define HKDF. ### Does TS 103 744 cover hybrid signatures? No. TS 103 744 is specifically about hybrid key exchange. Hybrid signatures are in different documents (IETF drafts on composite signatures, ETSI work in progress). The two domains have different combiners. ### Does QNSQY follow TS 103 744? QNSQY uses an HKDF-SHA-256 combiner over the X25519 and ML-KEM shared secrets, with file-specific context information binding the hybrid secret to the file's KEM choice and salt. This matches the TS 103 744 pattern. See [pricing](../../pricing.html). ### What about Triple-Hybrid (classical + PQC + PQC)? Some research proposes triple-hybrid combining classical, lattice-PQC, and code-PQC. TS 103 744 v1.x focuses on dual hybrid. Triple-hybrid is being studied for ultra-high-assurance use cases. QNSQY's Business tier could in the future combine X25519 + ML-KEM + HQC for triple-hybrid. ### How does TS 103 744 handle algorithm downgrade attacks? The combiner itself does not prevent downgrade. Downgrade protection is a property of the negotiation layer above the combiner. In TLS 1.3 the `signature_algorithms` extension and the transcript hash binding prevent an attacker from silently swapping the negotiated hybrid group for a weaker one. Implementations should treat the negotiated algorithm identifiers as part of the cryptographic transcript. ### Are there test vectors for the TS 103 744 combiner? Test vectors for the X25519 plus ML-KEM hybrid combiner are published as part of the IETF hybrid-design draft and the corresponding CFRG documents. ETSI does not publish a separate vector set, but the technical content is identical, so an implementation passing IETF vectors automatically satisfies TS 103 744. ## Sources 1. ETSI TS 103 744 v1.1.1, "CYBER; Quantum-safe Hybrid Key Exchanges," December 2020. https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf 2. IETF draft-ietf-tls-hybrid-design, "Hybrid key exchange in TLS 1.3." https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ 3. NIST SP 800-56C Rev 2, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes." https://csrc.nist.gov/pubs/sp/800/56/c/r2/final 4. IETF RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." https://datatracker.ietf.org/doc/html/rfc5869 5. Bindel, Brendel, Fischlin, Goncalves, Stebila, "Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange," IACR ePrint 2018/903. https://eprint.iacr.org/2018/903 6. NSA Commercial National Security Algorithm Suite 2.0, September 2022. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSI_CNSA_2.0_ALGORITHMS_.PDF 7. NIST IR 8528, "Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process," March 2025. https://csrc.nist.gov/pubs/ir/8528/final ## Related Articles - [ETSI quantum-safe standards](../etsi-quantum-safe-standards.html) - [ETSI TR 103 619](../etsi-tr-103-619.html) - [Hybrid encryption](../hybrid-encryption.html) - [ML-KEM explained](../ml-kem-explained.html) - [IETF PQUIP drafts](../ietf-pquip-drafts.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)