后量子密码学的安静落地
2024 年 8 月，NIST 正式发布了三项后量子密码学标准：FIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）。这件事在密码学圈子里是里程碑式的，在一般技术媒体里几乎没有引起波澜。
大多数工程师对量子计算的感知，停留在”实用量子计算机还很遥远”这个判断里。这个判断不完全错，但它遮住了一个更紧迫的现实：你今天传输的加密数据，攻击者可以存储下来，等到量子计算成熟时再解密。
这就是”先存储后解密”（Harvest Now, Decrypt Later）攻击。对于生命周期足够长的秘密——政府档案、金融合同、医疗数据——这个威胁是当下的，不是未来的。
现在用的密码学为什么会失效
现代 HTTPS 依赖两类算法：
一是用于密钥交换的非对称加密，典型是 ECDH 和 RSA。这类算法的安全性建立在大整数分解或离散对数的计算困难性上。Shor 算法在足够强大的量子计算机上可以在多项式时间内解决这两个问题。
二是用于签名的算法，同样面临 Shor 算法的威胁。
对称加密（AES）和哈希函数（SHA-256）受量子计算影响较小——Grover 算法可以将暴力破解速度提升到平方根倍，但这只需要把密钥长度翻倍就能应对。
换句话说，真正需要替换的是密钥交换和数字签名，不是加密算法本身。这个区分很重要。很多工程师一听”量子计算威胁密码学”就开始担心 AES，但实际上 AES-256 在量子计算时代依然安全，ECDH 和 RSA 才是要换掉的部分。
NIST 选了什么
经过从 2017 年开始、历时七年的评审，NIST 最终落地了以下标准：
ML-KEM（FIPS 203）：基于格密码学的密钥封装机制，前身是 CRYSTALS-Kyber。用于替换 ECDH 进行密钥交换。
ML-DSA（FIPS 204）：基于格密码学的数字签名算法，前身是 CRYSTALS-Dilithium。
SLH-DSA（FIPS 205）：基于哈希函数的数字签名算法，前身是 SPHINCS+。设计更保守，不依赖格密码学假设，定位是备用方案。
格密码学的核心安全假设是”带错误学习问题”（Learning With Errors，LWE）——目前没有已知的量子算法能高效解决这个问题。这是这类算法被信任的数学基础。
值得注意的是：CRYSTALS-FALCON 衍生的 FN-DSA 预计在 FIPS 206 里发布。它比 ML-DSA 的签名体积更小，但实现难度更高，容易引入时序侧信道，所以标准化节奏略慢。
代价有多大：真实的工程数字
后量子密码学最直接的工程代价是密钥和签名体积的膨胀。
拿 ML-KEM-768 和 X25519（当前常用的 ECDH 曲线）对比：
| X25519 | ML-KEM-768 | |
|---|---|---|
| 公钥大小 | 32 字节 | 1184 字节 |
| 密文（封装密钥） | 32 字节 | 1088 字节 |
| 运算速度 | 快 | 接近，甚至更快 |
公钥大了 37 倍，但运算速度的差距没有想象中大——格运算可以利用 SIMD 指令高效并行化，在现代 CPU 上 ML-KEM 的密钥生成速度与 X25519 相近。
签名算法的体积膨胀更明显：
| Ed25519 | ML-DSA-65 | |
|---|---|---|
| 公钥大小 | 32 字节 | 1952 字节 |
| 签名大小 | 64 字节 | 3309 字节 |
对 TLS 握手，这意味着握手数据包增大。对证书链，每个证书变大。对嵌入式设备，内存和存储约束可能成为真实瓶颈。这些代价不是灾难性的，但都需要在系统设计里考虑进去。
已经在发生的事
标准落地后，部署工作已经在静默推进。
TLS 里的混合方案是当前主流路线。Chrome 从 131 版本开始默认启用 X25519MLKEM768——把经典 X25519 和 ML-KEM-768 组合起来的混合密钥交换方案。逻辑是：如果格密码学假设出了问题，经典算法提供安全下限；如果量子计算机出现了，ML-KEM 部分保证前向安全。两条腿走路，不押单注。
Cloudflare、AWS、Google Cloud 都在测试后量子 TLS 支持，部分已经在生产环境里运行。
消息应用里走得更快。Signal 在 2023 年就升级协议引入了后量子密钥封装，Apple iMessage 在 2024 年的 PQ3 升级里加入了后量子保护。这两个产品的用户规模，让它们成为后量子密码学在消费市场最大规模的实际部署。
证书体系的迁移是最复杂的部分，也推进最慢。X.509 证书、CA 体系、浏览器信任列表——这套基础设施的更换涉及太多参与方，需要多年时间的协调。这里没有技术障碍，只有治理复杂度。
实现层的风险：侧信道不是理论
格密码学的安全性在数学上是清晰的，但实现安全是另一回事。
时序攻击（Timing Attack）对密码学实现来说是真实威胁。如果算法的执行时间依赖密钥值，攻击者可以通过观察时序来还原密钥。常数时间实现（Constant-Time Implementation）是密码学库的基本要求，但做到这一点在 C/C++ 里比想象中困难——编译器优化可能破坏常数时间性质，需要特别的编译器屏障或汇编实现。
这是为什么在格密码学实现里，FN-DSA（FALCON）的标准化和推广比 ML-DSA 慢的原因之一：FALCON 的 NTRU 格运算对常数时间实现的要求更苛刻，开源实现里曾经发现过侧信道问题。
从工程实践角度：不要自己实现这些算法。优先使用经过独立安全审计的成熟库，比如 liboqs（Open Quantum Safe 项目）、AWS-LC、或者 OpenSSL 3.5 的 ML-KEM 实现。
过渡期的工程决策
对大多数工程团队，现在需要做的不是立刻替换整个密码学栈，而是几件具体的事：
识别高风险数据：哪些数据的保密生命周期超过十年？密钥材料、合规档案、医疗记录。这些是”先存储后解密”攻击的目标，优先级最高。
跟踪依赖库的进展：OpenSSL 3.5 开始实验性支持 ML-KEM。BoringSSL（Chrome、Android 使用）已经在生产中部署。如果你的 TLS 库还没有支持计划，这是一个需要跟进的信号。
采用混合方案而非直接切换：在过渡期，混合密钥交换（经典算法 + 后量子算法）比单独切换到后量子算法更稳妥。既不降低当前安全性，又引入了后量子保护。这是当前推荐的工程路线，而非过渡性妥协。
不要等待完美时机：密钥材料的轮换需要时间，系统改造需要时间，依赖升级需要时间。如果等到量子威胁明确了再开始，迁移时间窗口会非常紧张。
结尾
量子计算机什么时候能真正威胁 RSA-2048？没有人知道准确答案。乐观预测是 2030 年代，悲观预测是更远。但”威胁时间线不确定”和”现在不需要行动”是两件不同的事。
标准已经落地，Chrome 已经在部署，Signal 和 iMessage 已经在运行，底层密码学库已经在实现。
这不是一场紧急响应，而是一个已知终点的长程工程任务。问题不是要不要迁移，而是从哪个节点开始把它纳入你的技术路线图。
等到量子计算机真的出现了再开始，大概是最糟糕的时间选择。