2026 年 10 月 12 日，Filippo Valsorda 在自己的博客发布了新版 Cryptographic Right Answers。这是一份每隔几年更新一次的文档，回答一个具体的问题：开发者在新项目里该用哪些密码学原语。这个系列从 Colin Percival 2009 年的版本开始，经过 Thomas Ptacek 2015 年的更新，Latacora 团队 2018 和 2024 年的两轮接棒，到这一版恰好是第五代。2018 年那一版在 Hacker News 拿下 340 分和 235 条评论，是这个系列影响力最高的一次。
这一版的核心变化写在开篇第一段：后量子迁移的时间线在 2026 年初被大幅提前，业内现在形成的共识是迁移需要在 2029 年前完成。Google 已在 2026 年 3 月宣布自家后量子迁移以 2029 年为期限，Cloudflare 的路线图同样指向 2029 年。留给整个互联网的时间是三年。
这份清单的运作方式
每一代 Right Answers 的格式都一样：按开发者实际会遇到的场景分类（加密数据、存密码、密钥交换、签名、TLS、备份），每个场景给出一个直接可用的答案，然后列出历代版本的答案做对照。读者可以一眼看到十七年间哪些答案没变过、哪些被彻底推翻。
2026 版的速查表是这样的：
| 场景 | 2026 版答案 |
|---|---|
| 数据加密 | 云上用 KMS；本地用 XAES-256-GCM 或 XChaCha20Poly1305（随机 nonce）；大文件用 Cobblestone-128 |
| 对称密钥长度 | 别纠结，要选就 256-bit |
| 对称"签名" | HMAC-SHA-256 |
| 哈希算法 | SHA-2 仍然没问题，多重哈希用 SequenceHash |
| 随机 ID | 32 字节随机数（256-bit） |
| 密码存储 | Argon2id 或 scrypt；优先考虑 passkeys |
| 密钥交换 | 标准协议里的 X25519+ML-KEM-768 |
| 非对称加密 | HPKE（MLKEM768-X25519）或带 PQ 密钥的 age |
| 非对称签名 | ML-DSA-44 |
| 网站/TLS | 云上用 ALB/NLB；自建用 rustls、Go crypto/tls、BoringSSL、AWS-LC 或 s2n-tls |
| 在线备份 | restic + 长随机密码 |
对照历史版本，对称密码这一半的答案几乎原封不动：HMAC-SHA-256 从 2009 年沿用至今，SHA-2 从 2015 年站到现在，256-bit 对称密钥的建议五版全同。被推翻的全部集中在非对称那一半。
非对称答案全变了
2018 版对密钥交换的回答还是"可能什么都不用，或者 Curve25519"。2024 版给出了 X25519+ML-KEM-768 的混合方案。2026 版的措辞升级了：不含 ML-KEM 的方案是"活跃的、紧急的负债"，因为 harvest-now-decrypt-later 攻击现在就在发生：攻击者录制加密流量存起来，等量子计算机成熟后回放解密。凡是有长期保密需求的数据（医疗记录、国家机密、多年期的商业合同），今天的录存就是未来的泄露。
具体的部署答案也齐全了：TLS 里用 X25519MLKEM768（需要 TLS 1.3），SSH 里用 mlkem768x25519-sha256，HPKE 和 age 里用 MLKEM768-X25519。OpenSSH 从 9.0（2022 年 4 月）起默认带后量子密钥交换，最初的 sntrup761x25519 到现在换成了 mlkem768x25519。浏览器侧，Chrome 从 124 版开始在所有桌面平台默认启用 X25519Kyber768（ML-KEM 的前身命名），到 2026 年 4 月，Cloudflare 观测到人工流量的三分之二以上已经用混合 ML-KEM 交换完成握手。这项迁移的客户端基础设施实际上已经铺完，剩下的是服务器端跟进。
签名这一半走得更激进。2024 版的建议还是"短生命周期用 Ed25519，长生命周期 Ed25519+ML-DSA-65 混合"；2026 版直接说：只用 ML-DSA-44，不要混合。理由有两个层次。一是 ML-DSA 本身的工程质量：自带对冲随机数（比纯随机和确定性 nonce 都好）、内建上下文绑定、SUF-CMA 安全性质、实现相对简单。二是混合签名的收益算不过来：如果你的密钥轮换策略足以应对"量子计算机没来但经典算法被攻破"的情形，那套策略同样覆盖量子场景；如果你的签名要活几十年，那混合方案里的经典算法反正活不到那时候。唯一的例外是 SSH：OpenSSH 10.6（2026 年 10 月 6 日发布）选了 ssh-mldsa44-ed25519 复合签名。作者认为这是个错误决策，但同时承认跟着走比另辟蹊径强。
参数选择的细节需要单独说明：签名用 ML-DSA-44 而密钥交换用 ML-KEM-768，两个数字不一致不是笔误。NIST 安全类别里 ML-KEM-512 是类别 1，ML-DSA-44 落在类别 2，已经在 128-bit 安全强度之上有余量，没必要为此付出更高参数集的签名体积代价。
对称密码：什么都没变，以及两个新东西
文章对 Grover 算法的表态比前几版更直接：Grover 不重要，128-bit 密钥的暴力搜索攻击不存在。对称密码不需要因为量子计算恐慌而加倍密钥长度，256-bit 的建议只是为了顺带挡住多目标攻击。Argon2id 的推荐参数维持 libsodium 的 INTERACTIVE 档（m=64 MiB, t=2, p=1），并且明确说别按 RFC 9106 的参数配，那会把生产系统拖死。bcrypt 这一版被移出了清单，原因是它的 72 字节截断问题真的会咬人。
对称部分真正的变化是两个新名字。一是 XAES-256-GCM，一个把标准 KDF 和 AES-GCM 组合成扩展 nonce AEAD 的构造，解决了随机 nonce 下 AES-GCM 只能安全加密约二十亿条消息的限制。二是 Cobblestone-128，一个 STREAM 变体，解决"单条消息超过几个 MB 就不该直接喂给 AEAD"的老问题——直接加密大消息意味着解密端必须先处理或存储未认证的明文。这两个设计都是作者本人的作品，文章用脚注做了利益披露，同时列出了第三方背书：XAES-256-GCM 进了 Google Tink，有 AWS 的安全分析，被微软官方 SDK 采用；Cobblestone-128 已进 pyca/cryptography，即将进 Go 标准库。
TLS 库的黑名单变长了
2026 版把网站和客户端-服务器应用合并成一个类目，答案的第一层是"在云上就用云的 ALB/NLB"。自建场景下 OpenSSL 第一次被降级出推荐名单：rustls 和 Go 的 crypto/tls（都是内存安全实现）排在前两位，附带的一条新建议更出乎意料：2026 年的现在，LLM 找漏洞的能力已经足够强，"用你能负担得起的最好的模型做一轮代码评审"正式进入 Cryptographic Right Answers，和"用内存安全语言"并列。
对普通开发者的操作顺序
把这份清单翻译成动作：第一，查自己的 TLS 栈，确认密钥交换里有 X25519MLKEM768，OpenSSL 要 3.5 以上，RHEL 9 系需要手动开启；第二，评估哪些数据有三年以上的保密需求，这些数据的传输路径优先迁移，这是 harvest-now-decrypt-later 唯一的解法；第三，新项目的签名直接上 ML-DSA-44，存量系统把 PQ 迁移排进路线图；第四，密码存储如果还在用 bcrypt，趁这次换成 Argon2id；第五，访问你服务的客户端有多少已经自带 PQ 能力，可以用 Cloudflare 的观测数据做参照——这一半的迁移不需要等任何人。
清单的最后一栏是备份：restic 加长随机密码。Tarsnap 十七年里一直是这个类目的标准答案，这一版被换掉了，原因是它的非对称层全是 RSA。作者补了一句公道话，Tarsnap 的设计让那些低权限密钥的实际风险可控，2008 年的设计能做到这个程度相当了不起。但在量子倒计时面前，一个 RSA 层的备份工具不再是"正确答案"。
三年时间，一代清单。这份文档自己的历史摆在那里：十七年里对称密码的答案几乎没动过，而非对称密码的答案在最近两版里被整体重写。开发者要做的不是恐慌，是把这张表贴到团队 wiki 上，逐行对照自己的系统。
来源：Filippo Valsorda, "(Post-Quantum) Cryptographic Right Answers", 2026-10-12；历史版本对照与 HN 历年数据见 Percival 2009、Ptacek 2015、Latacora 2018