3. PQC算法族与TLS适配性
把PQC搬进TLS，第一步不是改代码，而是判断“哪一类算法能替换TLS里的哪一个密码学角色”。TLS 1.3的握手把密码学能力拆成三块：密钥交换（KEM）、身份认证（签名）、以及贯穿全流程的哈希与KDF。PQC算法族恰好也按这三类分工，但它们的数学结构、公钥/密文尺寸、性能特征差异极大，选型时必须逐类对齐，而不是笼统地说“换成PQC”。
三类角色的替换关系
在TLS 1.3中，密钥交换由(EC)DHE完成，客户端和服务端各自生成临时密钥对，交换公钥后通过HKDF-Extract得到共享密钥。PQC中承担这一角色的是KEM（密钥封装机制），典型代表是ML-KEM（原CRYSTALS-Kyber，FIPS 203）。KEM的交互模型与DHE不同：客户端用服务端公钥封装出一个共享密钥并产生密文，服务端解封装得到同一密钥。因此TLS适配时，KEM的公钥放进key_share，密文作为响应返回，而不是像DHE那样双方各发一个公钥。
身份认证由签名完成。TLS 1.3用CertificateVerify消息证明持有私钥，PQC中对应的是ML-DSA（原CRYSTALS-Dilithium，FIPS 204）和SLH-DSA（原SPHINCS+，FIPS 205）。前者基于格问题，签名小、速度快；后者基于哈希，签名大、速度慢，但安全假设更保守。哈希与KDF层面，TLS 1.3已经使用SHA-256/SHA-384，PQC并不要求替换哈希，但ML-KEM和ML-DSA内部都依赖SHAKE/SHA-3，因此工程上需要确认密码库同时提供SHA-3族原语。
NIST标准化进展与状态
NIST在2024年8月正式发布了三项PQC标准：FIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）。这意味着PQC从“候选算法”进入“可合规部署”阶段。需要特别注意的是，FIPS 203/204/205是算法标准，并不等于TLS协议标准；TLS中如何携带这些算法的公钥、密文和签名，由IETF的draft-ietf-tls-mlkem、draft-ietf-tls-mldsa等文档定义。工程上必须同时跟踪两条线：NIST定算法，IETF定协议编码。
此外，NIST还在推进FN-DSA（Falcon，FIPS 206），它同样是格签名，但签名更短、验签更快，适合对带宽敏感的场景。不过Falcon的实现复杂度高，浮点运算和侧信道防护难度大，短期内工程落地不如ML-DSA广泛。选型时若没有极端尺寸约束，优先ML-DSA；若证书链必须压缩，再评估FN-DSA。
工程约束：尺寸是第一道门槛
PQC算法最直接的工程冲击是尺寸膨胀。以NIST Level 3为例，ML-KEM-768的公钥约1184字节、密文约1088字节；而X25519公钥仅32字节。ML-DSA-65的公钥约1952字节、签名约3309字节；ECDSA P-256签名仅约64字节。这些数字直接决定三件事：
- 握手分片：ClientHello中若携带ML-KEM公钥，可能超过单个TCP段，需要TLS分片或依赖TCP分段，增加握手RTT风险。
- 证书链：若服务端证书使用ML-DSA，证书链可能从几KB涨到十几KB，影响首包时延和移动网络体验。
- MTU与UDP：在QUIC/HTTP3场景下，过大的握手消息可能触发IP分片，需评估路径MTU。
因此，工程上普遍采用混合模式：密钥交换用X25519MLKEM768，即同时执行X25519和ML-KEM-768，把两个共享密钥拼接后送入HKDF。这样即使ML-KEM被攻破，X25519仍提供保护；反之亦然。签名侧则常采用“双证书”过渡：服务端同时持有ECDSA证书和ML-DSA证书，根据客户端能力选择。
选型标准与可执行判断
综合来看，选型可以按以下顺序推进。第一步定安全等级：一般业务选Level 3（ML-KEM-768 + ML-DSA-65），高安全场景选Level 5（ML-KEM-1024 + ML-DSA-87）。第二步看尺寸预算：若证书链必须控制在4KB以内，优先ML-DSA-44或评估FN-DSA；若可放宽到16KB，ML-DSA-65可用。第三步看性能预算：ML-KEM封装/解封装在主流服务器上约几十微秒，ML-DSA签名约百微秒级，验签约几十微秒，通常不是瓶颈，但高QPS网关需实测。第四步确认库支持：OpenSSL 3.5已内置ML-KEM/ML-DSA，oqs-provider可提供更早的实验支持，BoringSSL和部分云厂商SDK也已跟进。
openssl list -kem-algorithms查看ML-KEM支持情况，用openssl genpkey -algorithm ML-KEM-768生成测试密钥。TLS握手测试可先用openssl s_server -groups X25519MLKEM768启动服务端，再用openssl s_client -groups X25519MLKEM768验证协商结果，观察Server Temp Key字段是否显示混合组名。
小结：三类角色的选型结论
KEM选ML-KEM，优先768或1024，配合X25519做混合；签名选ML-DSA，优先65，证书链受限时考虑44或FN-DSA；哈希不替换，但必须确保SHA-3/SHAKE可用。NIST标准已就位，IETF协议编码仍在推进，工程落地应以“混合模式+双证书”为过渡主线，先保证互通，再逐步收紧到纯PQC。