Hybrid Cryptography
A hybrid scheme combines a classical algorithm and a post-quantum algorithm so that the result stays secure as long as either component holds. It lets you deploy PQC today while hedging against both immature PQC implementations and a future quantum attacker — and in some jurisdictions and high-assurance settings, regulators and guidance favor or require it during the transition.
Why hybrid
The PQC standards are new, and their implementations have far less field exposure than RSA or elliptic curve. A hybrid construction hedges two distinct risks at once:
- Quantum risk against the classical component — covered by the PQC half.
- Implementation/cryptanalytic risk against the young PQC component — covered by the well-understood classical half.
You only lose security if both halves fail, which is far less likely than either failing alone. This is why BSI and ANSSI guidance leans toward — and in defined contexts requires — hybrid deployments during the transition period.
Hybrid key exchange and KEM combiners
In a hybrid key exchange, each party runs both a classical key agreement (e.g. X25519 or ECDH) and a PQC KEM (ML-KEM). You then have two shared secrets that must be combined into one key. The combination is done by a KEM combiner — a KDF that takes both secrets (plus transcript/context) as input:
ss_classical = X25519(...) # classical shared secret
ss_pqc = ML-KEM-768.decap(...) # post-quantum shared secret
session_key = KDF( ss_classical || ss_pqc || transcript )Because the KDF consumes both secrets, an attacker must break both to recover the session key. A poorly designed combiner that simply XORs or uses only one secret defeats the purpose — always feed both through a proper KDF bound to the handshake transcript.
The distinction between separable and non-separable hybrids is whether the classical and PQC components can be independently identified, replaced, or stripped out at the protocol layer; real constructions are typically achieved through KEM combiners, KDF binding, and the protocol transcript, rather than being understood simply as "encrypt with one algorithm, then re-encrypt with another."
The IETF has standardized the vocabulary for this design space in RFC 9794 ("Terminology for Post-Quantum Traditional Hybrid Schemes"), giving precise terms such as PQ/T hybrid that the protocol working groups now build on. A general-purpose hybrid KEM, X-Wing (draft-connolly-cfrg-xwing-kem), packages X25519 + ML-KEM-768 with a fixed combiner so applications can drop in one ready-made hybrid KEM rather than wiring the combiner themselves. X-Wing is currently an Internet-Draft, not an RFC; it can serve as an engineering reference or a basis for experimental implementations, but should not be described as a formal standard.
X25519MLKEM768 in TLS
The flagship hybrid group for TLS 1.3 is X25519MLKEM768: it pairs X25519 with ML-KEM-768. Key facts:
- IANA-registered named group, codepoint 0x11EC.
- Earlier draft deployments used the name X25519Kyber768 (Kyber was renamed ML-KEM when standardized as FIPS 203).
- X25519MLKEM768 has become one of the most important interoperability targets for hybrid key exchange in TLS 1.3, and is being deployed across mainstream browser/CDN ecosystems.
# Negotiate hybrid PQC key exchange in TLS 1.3 (OpenSSL with PQC provider)
openssl s_client -connect example.com:443 \
-groups X25519MLKEM768See TLS for full handshake details and fallback behavior.
Composite and hybrid signatures
Signatures can be hybridized too. A composite signature binds a classical and a PQC signature together into a single artifact that verifies only if both component signatures verify — for example composite ML-DSA + ECDSA. This gives certificates and code-signing the same dual-assurance property as hybrid KEX, at the cost of larger signatures and certificates (see PKI Impact).
Costs and caveats
- Size. You transmit two public keys/ciphertexts or two signatures — bandwidth and certificate sizes grow.
- Complexity. Two algorithms means two failure modes to test and two key-management paths.
- Combiner correctness. The security proof depends on a sound KDF construction — do not invent your own.
Standards & references
混合密码
混合方案将经典算法与后量子算法组合在一起 只要其中任一组件保持安全 整体即保持安全。它让你今天就能部署 PQC 同时对冲不成熟的 PQC 实现与未来的量子攻击者两重风险——而且在部分国家和高保障场景中，监管/指南倾向于或要求过渡期采用混合方案。
为何混合
PQC 标准尚新 其实现的实战暴露远少于 RSA 与椭圆曲线。混合构造同时对冲两种不同风险：
- 针对经典组件的量子风险——由 PQC 那一半覆盖。
- 针对年轻 PQC 组件的实现与密码分析风险——由成熟的经典那一半覆盖。
只有当两半同时失守时你才会丧失安全性 这远比任一单独失守的概率低得多。这正是 BSI 与 ANSSI 的指南在过渡期倾向于（并在特定场景下要求）混合部署的原因。
混合密钥交换与 KEM 组合器
在混合密钥交换中 双方同时执行一次经典密钥协商（如 X25519 或 ECDH）与一次 PQC KEM（ML-KEM）。于是你得到两个共享密钥 需合并为一把密钥。合并由 KEM 组合器完成——一个把两个密钥（外加握手记录/上下文）作为输入的 KDF：
ss_classical = X25519(...) # 经典共享密钥
ss_pqc = ML-KEM-768.decap(...) # 后量子共享密钥
session_key = KDF( ss_classical || ss_pqc || transcript )由于 KDF 同时消费两个密钥 攻击者必须同时攻破两者才能还原会话密钥。设计拙劣的组合器若只做简单异或或仅用其中一个密钥 便会前功尽弃——务必将两者都通过一个绑定握手记录的正规 KDF。
可分离/不可分离混合的区别在于经典与 PQC 组件是否能被协议层独立识别、替换或剥离；实际构造通常通过 KEM 组合器、KDF 绑定和协议 transcript 完成，而不应简单理解为"先用一种算法加密、再用另一种算法二次加密"。
IETF 已在 RFC 9794（"后量子与传统混合方案术语"）中标准化了这一设计领域的词汇 给出 PQ/T hybrid 等精确术语 供各协议工作组在其上构建。通用混合 KEM X-Wing（draft-connolly-cfrg-xwing-kem）把 X25519 + ML-KEM-768 与固定组合器打包在一起 让应用可直接接入一个现成的混合 KEM 而无需自行搭建组合器。X-Wing 目前仍是 Internet-Draft，并非 RFC；可作为工程参考或实验实现依据，但不应称为正式标准。
TLS 中的 X25519MLKEM768
用于 TLS 1.3 的旗舰混合群组是 X25519MLKEM768：它将 X25519 与 ML-KEM-768 配对。要点：
- 已在 IANA 注册的命名群组 码点为 0x11EC。
- 早期草案部署使用名称 X25519Kyber768（Kyber 在标准化为 FIPS 203 时更名为 ML-KEM）。
- X25519MLKEM768 已成为 TLS 1.3 混合密钥交换中最重要的互操作目标之一，并已在主流浏览器/CDN 生态中开展部署。
# 在 TLS 1.3 中协商混合 PQC 密钥交换（带 PQC provider 的 OpenSSL）
openssl s_client -connect example.com:443 \
-groups X25519MLKEM768完整握手细节与回退行为参见 TLS。
复合签名与混合签名
签名同样可以混合化。复合签名将一个经典签名与一个 PQC 签名绑定为单一产物 仅当两个分量签名都验证通过时整体才通过——例如复合 ML-DSA + ECDSA。这让证书与代码签名获得与混合密钥交换相同的双重保障 代价是更大的签名与证书（参见 PKI 影响）。
成本与注意事项
- 尺寸。你需传输两份公钥/密文或两份签名——带宽与证书尺寸随之增长。
- 复杂度。两种算法意味着两条失效路径需测试 两套密钥管理流程。
- 组合器正确性。安全证明依赖于稳健的 KDF 构造——切勿自创。