3. NIST PQC标准算法选型对比与适用场景判断
选型先看约束：两类需求对应两族算法
企业做PQC选型时，最容易犯的错误是“挑一个最强的算法全局替换”。实际上，密钥封装（KEM）和数字签名是两类完全不同的密码学需求，NIST标准化的算法族也分别对应：ML-KEM（FIPS 203）用于密钥建立，ML-DSA（FIPS 204）与SLH-DSA（FIPS 205）用于签名。选型的第一步不是比性能，而是先把业务需求映射到正确的算法族，再在族内比较尺寸、性能与安全假设。
下面这张图把三类标准算法的关键工程属性放在同一坐标系中对比，并标出它们各自最适合落位的企业场景。图中尺寸数据为NIST标准中对应安全级别的公开参数（ML-KEM-768、ML-DSA-65、SLH-DSA-SHA2-128s），用于选型判断而非实测。
把参数放进业务约束里比较
单看“公钥1184字节”没有意义，必须换算成业务影响。下表把三类算法放到企业常见场景的约束条件下，给出可操作的判断依据。表中尺寸为NIST标准公开参数，性能描述为相对定性判断，实际数值需在目标硬件上实测。
| 对比维度 | ML-KEM-768 | ML-DSA-65 | SLH-DSA-SHA2-128s |
|---|---|---|---|
| 用途 | 密钥封装 | 数字签名 | 数字签名 |
| 安全假设 | 模格MLWE | 模格MLWE+MSIS | 仅哈希函数 |
| 公钥尺寸 | 1184 B | 1952 B | 32 B |
| 密文/签名尺寸 | 密文1088 B | 签名3309 B | 签名7856 B |
| 握手/验签开销 | 低，适合高频 | 中，证书链膨胀明显 | 高，签名慢 |
| 典型企业落位 | TLS/VPN会话密钥 | 终端证书、代码签名 | 根CA、固件根信任 |
| 主要风险点 | 报文变大触发分片 | 证书体积与兼容性 | 吞吐与延迟不达标 |
一个可直接套用的选型判断示例
假设某企业有三类待改造对象，按上面的判断顺序逐一落位：
- 对外Web服务的TLS 1.3握手：属于密钥建立，选ML-KEM-768，并与X25519做混合密钥交换，兼顾兼容性与抗量子性。需重点验证握手报文增大后是否触发中间设备分片问题。
- 内部服务间mTLS的终端证书：属于签名，选ML-DSA-65。需评估证书链从ECDSA切换到ML-DSA后，单次握手的证书传输字节增量，以及旧客户端是否支持新签名算法。
- 设备固件根信任与长期归档签名：属于签名，且要求安全假设最保守、调用频率低，选SLH-DSA。签名体积大、速度慢在此场景可接受，因为验签发生在启动或归档校验等低频路径。
选型结论应写成“算法+参数集+落位系统+验证指标”四元组，例如“ML-KEM-768 / 对外TLS握手 / 握手成功率≥99.9%、P95握手延迟增量≤15ms”，而不是只写算法名。参数集（如-768、-65、-128s）直接决定尺寸与安全级别，不能省略。
不要用“ML-KEM更小所以全面替换ML-DSA”这类跨族比较做决策。KEM与签名不可互换；SLH-DSA公钥虽只有32字节，但签名高达7856字节，把它用于高频在线验签会直接拖垮吞吐。选型必须先在需求族内收敛，再比较参数集。
选型交付物：算法选型对照表
把上述判断固化成一张可填写的对照表，作为后续改造任务的输入。字段只保留选型真正需要的项，避免引入无关管理字段。
| 业务对象 | 密码需求 | 候选算法/参数集 | 关键约束 | 验证指标 | 结论 |
|---|---|---|---|---|---|
| 对外Web TLS握手 | 密钥建立 | ML-KEM-768 + X25519 | 中间设备分片、客户端兼容 | 握手成功率、P95延迟增量 | 混合部署 |
| 内部mTLS终端证书 | 签名 | ML-DSA-65 | 证书链体积、旧客户端支持 | 证书验证通过率、握手字节增量 | 替换并灰度 |
| 固件根信任/归档签名 | 签名 | SLH-DSA-SHA2-128s | 低频调用、最保守假设 | 验签耗时、签名存储占用 | 采用 |
填完这张表，选型任务即闭环：每个业务对象都有明确的算法族归属、参数集、约束条件和可验证指标，后续的部署验证与兼容性测试可以直接以此为输入展开。