NIST 正在推进 9 个新的后量子签名算法，未来它们可能进入标准化流程。这是好消息，但工程决策不能只盯着“更好的算法还在路上”。签名算法通常嵌在证书、固件更新、软件包发布、审计日志和身份系统里，迁移周期长、依赖面宽。文章的核心判断很直接：候选算法值得跟踪，但现在可落地的选择应优先使用 ML-DSA。
为什么不能等下一批算法成熟
后量子迁移不是把一个函数名从 RSA_sign 改成 pqc_sign。签名算法会进入协议、密钥管理、硬件安全模块、证书链、合规文档和故障恢复流程。等到“完美算法”出现再开始，实际风险是所有系统同时排队改造。
NIST 推进 9 个新签名候选算法，说明这个领域仍在快速演进。新算法可能在签名大小、验证速度、公钥尺寸、实现复杂度或特定场景安全性上取得更好的平衡。但“有潜力”不等于“现在适合生产默认值”。标准化、实现审计、库支持、互操作测试和运维经验都需要时间。
ML-DSA 的优势不在于它永远最好，而在于它是当前最适合先部署、先积累经验的选择。对工程团队来说，这个差别很关键：你需要的是可执行的迁移路径，而不是算法竞赛的最终排名。
9 个候选算法意味着什么
新的候选算法更像是下一轮工具箱扩容，而不是对当前部署路线的否定。NIST 持续推进候选算法，说明后量子签名不会只有一种形态。未来可能出现更适合小设备、更适合大规模验证、更适合长期归档，或者更适合特殊信任模型的方案。
但候选阶段的算法有几个边界需要正视：
- API 和编码格式可能变化，早期集成成本可能被未来版本推翻。
- 实现生态还不够厚，出问题时很难找到成熟的兼容矩阵和排障经验。
- 安全分析还在继续，参数集、使用建议和边界条件可能调整。
- 供应链支持慢于论文和标准草案，尤其是 HSM、证书系统、CI/CD 签名链路。
所以更务实的策略是：生产默认采用 ML-DSA，同时把新候选算法放进实验轨道。不要把实验轨道误当生产基线，也不要因为实验轨道存在就推迟生产迁移。
可以这样实践：先做算法能力探测和签名试验
下面的示例不是声称所有环境都已经内置 ML-DSA，而是一个可改造的落地方式：在 CI 或构建机里检测 OpenSSL 是否支持 ML-DSA；如果支持，就生成测试密钥并完成一次签名/验签。你需要使用带 ML-DSA 支持的 OpenSSL 版本或对应 provider。
保存为 check-mldsa.sh 后运行：
#!/usr/bin/env bash
set -euo pipefail
ALG="${1:-mldsa65}"
MSG="message.txt"
SIG="message.sig"
PUB="mldsa.pub"
PRIV="mldsa.key"
echo "hello post-quantum signatures" > "$MSG"
if ! openssl list -signature-algorithms 2>/dev/null | grep -iE "ml-?dsa|${ALG}" >/dev/null; then
echo "ML-DSA does not appear to be available in this OpenSSL environment." >&2
echo "Use an OpenSSL build/provider that exposes ML-DSA, then rerun this script." >&2
exit 2
fi
openssl genpkey -algorithm "$ALG" -out "$PRIV"
openssl pkey -in "$PRIV" -pubout -out "$PUB"
openssl pkeyutl -sign -inkey "$PRIV" -in "$MSG" -out "$SIG"
openssl pkeyutl -verify -pubin -inkey "$PUB" -in "$MSG" -sigfile "$SIG"
echo "ML-DSA signing and verification succeeded with algorithm: $ALG"
运行：
chmod +x check-mldsa.sh
./check-mldsa.sh mldsa65
如果你的 OpenSSL 暴露的算法名不同，改脚本第一行参数即可，例如：
./check-mldsa.sh ML-DSA-65
这类脚本适合放进迁移前检查清单：构建镜像、发布机、测试环境、离线签名机分别跑一遍，先确认“工具链能不能签、能不能验、产物能不能被下游解析”。
从 RSA/ECDSA 迁到 ML-DSA，不要只替换密钥
签名算法替换会改变多个工程假设。ML-DSA 的签名和公钥尺寸与传统算法不同，很多老系统暗含了长度上限。例如数据库字段、HTTP header、JWT 扩展、固件 manifest、二维码载荷、日志字段，都可能因为尺寸变化出问题。
可以先做一个签名资产盘点表：
signature_migration_inventory:
artifact_signing:
current_algorithm: "ECDSA P-256"
target_algorithm: "ML-DSA"
owner: "release-engineering"
risk: "package registry and installer must accept larger signatures"
firmware_update:
current_algorithm: "RSA-3072"
target_algorithm: "ML-DSA"
owner: "device-platform"
risk: "bootloader storage and verification time need measurement"
audit_log:
current_algorithm: "Ed25519"
target_algorithm: "ML-DSA"
owner: "security-platform"
risk: "log schema may assume fixed signature length"
tls_or_pki:
current_algorithm: "mixed"
target_algorithm: "evaluate ML-DSA readiness"
owner: "infra-security"
risk: "CA, clients, appliances, and monitoring tools need compatibility tests"
这份 YAML 本身不解决密码学问题，但它能避免迁移项目变成“安全团队换了算法，业务系统才发现字段放不下”。
建议路线：生产用 ML-DSA，实验跟踪候选算法
更稳妥的采用方式可以分成三条线：
- 新系统优先设计后量子签名接口，不把签名长度、算法名、密钥类型写死。
- 现有系统选择一两个低风险签名场景先接入 ML-DSA，比如内部构建产物签名、离线归档签名或测试环境证书链。
- 对 NIST 推进的 9 个候选算法建立观察清单，记录库支持、参数变化、标准状态和适用场景。
需要注意的是，ML-DSA 不是“迁移结束”的同义词。它是当前可用性、安全性和标准化成熟度之间的务实折中。未来某个候选算法可能在你的场景里更合适，但那应该通过测试数据和互操作结果进入路线图，而不是让今天的迁移停摆。
检查清单可以很短：
- 你的签名系统是否支持算法敏捷性？
- 签名、公钥、证书或 manifest 的尺寸上限是否测过？
- CI、发布机、离线签名机是否具备 ML-DSA 工具链？
- 验签方是否能处理新算法和新编码？
- 是否为新候选算法保留实验环境，而不是直接压进生产链路？
后量子签名的最佳策略不是等待，而是把可用的标准化方案先纳入工程现实。ML-DSA 现在承担的就是这个角色：先让系统学会后量子签名，再等待下一批算法用数据证明自己值得进入生产。