PQC in Network Protocols
Post-quantum cryptography only protects real traffic once it lands inside the protocols that carry that traffic: TLS, SSH, IPsec/IKEv2, and the X.509 / CMS machinery that underpins them. This section explains how each protocol is being upgraded, and why the migration follows a consistent order: key exchange first, authentication later.
Why key exchange comes first
The dominant near-term threat is Harvest Now, Decrypt Later (HNDL): an adversary records encrypted sessions today and decrypts them once a cryptographically relevant quantum computer exists. HNDL attacks the confidentiality of past traffic, and confidentiality depends on the session keys produced by the handshake's key exchange. A signature, by contrast, only needs to resist forgery during the brief moment a connection is being authenticated — a recorded handshake cannot be retroactively forged.
So the industry upgrades key exchange first, almost always as a hybrid (classical + PQC) construction so that a flaw in the young PQC algorithm cannot weaken the connection below today's baseline. Authentication — PQC signatures embedded in certificates — lags behind, largely because PQC public keys and signatures are far larger than ECDSA/RSA, and certificate chains are sent on every handshake.
Status at a glance
| Protocol | Mechanism | Standard / spec | Availability |
|---|---|---|---|
| TLS 1.3 | Hybrid key exchange X25519MLKEM768 (0x11EC / 4588, Recommended) | IETF TLS ECDHE-MLKEM specification / registered IANA TLS NamedGroup; ML-KEM per FIPS 203. Once a formal RFC number is published, it should replace this reference. | OpenSSL 3.5+, BoringSSL; Chrome & Firefox (~2024) |
| TLS 1.3 (auth) | PQC signatures in certs / KEMTLS | IETF research & drafts | Experimental |
| SSH | sntrup761x25519-sha512, mlkem768x25519-sha256 | OpenSSH design | Widely deployed since OpenSSH 9.x; mlkem768x25519-sha256 is the default key-agreement algorithm since OpenSSH 10.0 |
| IPsec / IKEv2 | PPK (RFC 8784) + multiple key exchanges (RFC 9370) | RFC 8784, RFC 9242, RFC 9370 (RFC 9370 is the multiple-key-exchange framework, not the ML-KEM transform itself); the specific ML-KEM binding is in draft-ietf-ipsecme-ikev2-mlkem. | strongSwan, libreswan |
| X.509 / PKI | ML-DSA / SLH-DSA certs; composite & hybrid certs | IETF LAMPS has published the corresponding RFCs: in X.509, ML-DSA is RFC 9881, SLH-DSA is RFC 9909, ML-KEM is RFC 9935; in CMS, ML-DSA is RFC 9882, SLH-DSA is RFC 9814, ML-KEM is RFC 9936. | Tooling emerging |
| CMS / S-MIME | PQC signatures & KEM key transport | IETF LAMPS | Tooling emerging |
A consistent migration shape
- Add hybrid key exchange. Negotiate a PQC KEM alongside the existing classical group so confidentiality is quantum-safe immediately, with a classical safety net.
- Make it negotiable. Every protocol advertises supported groups/algorithms so old and new peers interoperate; PQC is just another offered option.
- Upgrade authentication. Roll out PQC signatures in certificates and host keys once tooling, OIDs, and chain-size handling mature.
Where to read next
Each protocol has its own page with concrete configuration and CLI examples. Start with the transport you operate most.
Standards & references
- RFC 9794 — PQ/T hybrid terminology used across protocol specs.
- TLS hybrid draft (X25519MLKEM768) — hybrid key exchange for TLS 1.3.
- RFC 9370 — multiple key exchanges in IKEv2 for hybrid IPsec.
- Open Quantum Safe — open-source PQC implementations and protocol integrations.
- Resources — full standards register
网络协议中的后量子密码
后量子密码只有真正落到承载流量的协议里才能保护通信：TLS、SSH、IPsec/IKEv2 以及支撑它们的 X.509 / CMS 体系。本节说明每个协议如何升级，以及为什么迁移遵循同一条主线——先换密钥交换，再换身份认证。
为什么先做密钥交换
当前最现实的威胁是 先收集、后解密（Harvest Now, Decrypt Later, HNDL）：攻击者今天先把加密会话录下来，等具备实用价值的量子计算机出现后再解密。HNDL 攻击的是历史流量的机密性，而机密性取决于握手阶段密钥交换产出的会话密钥。签名则不同，它只需在连接被认证的那一瞬间抵抗伪造——已录下的握手无法被事后伪造。
因此业界优先升级密钥交换，并且几乎都采用混合（经典 + 后量子）构造，确保年轻的后量子算法即使出问题也不会把连接拉低到现有基线之下。身份认证——把后量子签名嵌入证书——则相对滞后，主要原因是后量子公钥和签名远大于 ECDSA/RSA，而证书链在每次握手时都要传输。
整体进展一览
| 协议 | 机制 | 标准 / 规范 | 可用性 |
|---|---|---|---|
| TLS 1.3 | 混合密钥交换 X25519MLKEM768（0x11EC / 4588，Recommended） | IETF TLS ECDHE-MLKEM 规范 / IANA TLS NamedGroup 已登记；ML-KEM 依据 FIPS 203。若正式 RFC 编号已发布，应替换为 RFC 编号。 | OpenSSL 3.5+、BoringSSL、Chrome 与 Firefox（约 2024） |
| TLS 1.3 认证 | 证书中的后量子签名、KEMTLS | IETF 研究与草案 | 实验阶段 |
| SSH | sntrup761x25519-sha512、mlkem768x25519-sha256 | OpenSSH 设计 | OpenSSH 9.x 起广泛部署；OpenSSH 10.0 起 mlkem768x25519-sha256 成为默认密钥协商算法。 |
| IPsec / IKEv2 | PPK（RFC 8784）+ 多重密钥交换（RFC 9370） | RFC 8784、RFC 9242、RFC 9370；其中 RFC 9370 是多重密钥交换框架，并非 ML-KEM 变换本身，ML-KEM 具体绑定见 draft-ietf-ipsecme-ikev2-mlkem。 | strongSwan、libreswan |
| X.509 / PKI | ML-DSA / SLH-DSA 证书、复合与混合证书 | IETF LAMPS 已发布相应 RFC：X.509 中 ML-DSA 为 RFC 9881，SLH-DSA 为 RFC 9909，ML-KEM 为 RFC 9935；CMS 中 ML-DSA 为 RFC 9882，SLH-DSA 为 RFC 9814，ML-KEM 为 RFC 9936。 | 工具链逐步成熟 |
| CMS / S-MIME | 后量子签名与 KEM 密钥传输 | IETF LAMPS | 工具链逐步成熟 |
统一的迁移路径
- 加入混合密钥交换：在原有经典分组旁并行协商一个后量子 KEM，机密性立即获得量子安全保障，同时保留经典安全网。
- 让它可协商：每个协议都通告自身支持的分组/算法，新旧两端得以互通，后量子只是多了一个可选项。
- 升级身份认证：待工具链、OID 和证书链尺寸处理成熟后，再在证书和主机密钥中推广后量子签名。
继续阅读
每个协议都有单独页面，附带具体配置与命令行示例。建议从你运维最多的传输协议看起。
标准与参考
- RFC 9794 — 各协议规范通用的 PQ/T 混合术语。
- TLS hybrid draft (X25519MLKEM768) — TLS 1.3 的混合密钥交换。
- RFC 9370 — IKEv2 多重密钥交换，用于混合 IPsec。
- Open Quantum Safe — 开源 PQC 实现与协议集成。
- 资源链接 — 完整标准登记册