量子计算的威胁正在迫近，互联网证书颁发机构开始行动——Let's Encrypt宣布后量子证书路线图：Merkle树证书或将重塑Web安全基础设施。

时间窗口正在收窄

2026年6月3日，全球最大的免费证书颁发机构 Let's Encrypt 发布博客文章，正式宣布其后量子密码学迁移计划——以 Merkle Tree Certificates（MTC，默克尔树证书）为核心路径，目标是在不牺牲性能的前提下，为 Web PKI 引入后量子身份认证能力。

长期以来，后量子密码学的讨论几乎被「加密」问题所主导：攻击者可以今天录下你的加密流量，等到量子计算机成熟后再解密，即所谓的「现在收割，以后解密」（Harvest Now, Decrypt Later，HNDL）攻击。相比之下，身份认证（即 TLS 握手中证明服务器身份的部分）被认为没那么紧迫——毕竟伪造签名需要量子计算机实时在线，而非事后破解。

然而这种安逸正在消散。美国国家安全局（NSA）的 CNSA 2.0 套件已要求国家安全系统在2030至2035年间完成后量子迁移；欧盟路线图要求高风险系统在2030年底前完成迁移。今年，Google 宣布将在 2029年 前完成其服务的迁移，理由是密码学相关量子计算机（CRQC）出现的时间预期正在提前；Cloudflare 随即跟进。与此同时，Go 1.27 已将 ML-DSA（NIST 标准化的后量子签名方案）纳入标准库。

身份认证的后量子迁移，已经不是可以拖延的问题。

症结所在：签名体积的暴涨

Web PKI 是部署后量子签名最棘手的场景之一，原因只有两个字：体积。

当前 TLS 握手中，一次典型的 Web PKI 握手携带五个签名和两个公钥：

• ECDSA-P256：合计约 448 字节

• RSA-2048：合计约 1,792 字节

• ML-DSA-44（NIST后量子标准）：合计约 14,724 字节，超过 14KB

ML-DSA-44 的单个签名长达 2,420 字节，公钥 1,312 字节，而 ECDSA-P256 的签名仅 64 字节、公钥 64 字节。一旦直接替换，单次 TLS 握手数据量将突破 10KB。Cloudflare 的研究表明，在这种体量下，现实网络中会有相当比例的 TLS 连接直接失败，其余连接也会显著变慢。

这是一个两难困境：为了对抗一个尚未出现的威胁，让每一次 HTTPS 连接都付出代价——而「默认行为」才是真正决定 Web 安全基线的关键。

Merkle树证书：另辟蹊径

Let's Encrypt 的解法是 Merkle Tree Certificates（MTCs）。

其核心思路是：证书不再逐一签发，而是批量打包，用 单一签名 覆盖整批证书，生成一棵 Merkle 树。浏览器通过独立于 TLS 握手的渠道，预先同步这些批次签名（称为「路标」，landmark）。

在常规情况下，整个 MTC 握手的认证负载仅包含：一个签名 + 一个公钥 + 一个包含性证明（inclusion proof），合计约 736 字节——比当前 ECDSA 方案还小，尽管底层已使用后量子算法。

此外，MTC 还天然内置了证书透明度（Certificate Transparency）。当前 CT 生态是「事后打补丁」——CA 签发证书后再单独记录日志，TLS 握手中附带额外签名证明已记录。而在 MTC 体系下，一张证书若不在 Merkle 树中，则根本不存在，透明度成为发行过程本身的属性。

目前，Cloudflare 和 Chrome 已针对真实互联网流量开展 MTC 可行性实验；IETF 的 PLANTS 工作组正在推进标准化；Chrome 已明确表示 MTC 是其为公共网络添加后量子证书的首选路径。

Let's Encrypt 自 2019 年起已运营 CT 日志（同为追加式 Merkle 树结构），为此次迁移提供了工程基础。

计划时间线：

• 2026年底：发布 MTC 测试（staging）环境

• 2027年：正式推出生产就绪环境

HackerNews社区的激辩

这篇公告在 Hacker News 引发了数百条讨论，话题从 Merkle 树的工程细节，一路延伸到量子威胁是否被过度渲染、混合密码学的正确姿势，乃至科幻小说中的密码学描写。

「量子破解AES」是好莱坞剧情

围绕对称密码学是否需要后量子迁移，用户 tialaramex 给出了技术上颇为清醒的分析：AES 的密钥和块长度都是指数级意义上足够大的，即便量子计算机将穷举搜索速度翻倍，也远未达到实际破解的门槛。「量子计算机破解AES」是好莱坞电影的情节，现实中并不成立。真正面临威胁的，是 RSA、椭圆曲线等 非对称密码体制。

这一观点得到了 mswphd 的补充：目前对对称密码学最强的量子攻击是基于 Grover 算法的，但针对特定构造也存在一些更优化的攻击。他引用了相关论文，提醒不应因「Grover算法是上限」的传统观点而忽视这一潜在风险。

签名的紧迫性被严重低估

用户 tomgag 对行业中流行的「HNDL才是紧迫威胁，签名可以等」论调提出了批评。他指出两个被忽视的问题：

第一，签名的迁移路径往往比加密更复杂——固件更新密钥、安全启动证书、长期身份系统，这些都极难快速迁移。

第二，更深刻的一点：「事后」是相对于什么而言的？ 如果攻击者已经拥有了密码学相关量子计算机，量子伪造签名与密钥泄露、代码漏洞或经典破解在操作层面 无从区分。你可能看到一个伪造的签名、一个被清空的钱包，却无法判断这是量子攻击所为。「针对不可观测触发事件的被动迁移，在结构上就是不可能的。」

这一观点引发共鸣，也有用户 thyristan 反驳：Web PKI 场景下 TLS 连接本身只存活几天，签名的生命周期并不长，紧迫性未必如此高。

混合密码学：怎么「混」至关重要

讨论中，用户 chadgpt3 建议「用量子安全算法和经典算法各加密一次数据，两层保护」——这句话立刻引来了 some_furry 的纠正：

「如果你把数据加密两次，量子计算机破解了其中一层，攻击者照样能得到明文。」

正确的做法是使用 混合KEM（密钥封装机制）：分别用经典算法（如 X25519）和后量子算法（如 ML-KEM-768）各生成一个共享密钥，将两者安全组合后，再用这个组合密钥对数据加密 一次。安全性保证在于：只要两个 KEM 中有一个未被破解，组合密钥就安全。

这场关于「encrypt twice」与「hybrid KEM」的讨论延续了数十条回复，折射出密码学社区在向普通技术人员传达准确概念时面临的困境。用户 mswphd 一针见血地指出，签名场景下的混合方案（composite signatures）实际上比加密场景复杂得多，甚至存在安全性退化的问题，不能简单类比。

科幻小说里的密码学

一个有趣的岔路话题来自用户 skmurphy，他提到科幻作家 Vernor Vinge 在小说《深渊上的火》中描写了一种高价值货物：一次性密码本（OTP），被拆分为三份独立运输，到达目的地后 XOR 合并——这与今天的量子时代密码运输概念惊人相似。

用户 zetsurin 指出，Vinge 本人是数学与计算机科学教授，技术描写的准确性值得信赖；而用户 wisemang 则补充，这段情节还暗示了 Shamir 秘密共享算法——同样具有信息论安全性，而非依赖计算难度假设。

批量证书的新问题：等待时间

用户 LoganDark 提出了一个实际工程问题：MTC 采用批量签发，如果批次间隔太短，客户端要维护的数据库会过大；间隔太长，新站点申请到首张证书的等待时间会很长。

来自 Let's Encrypt 的工程师 mcpherrinm 回复称：目前计划批次生成时间在0.5到5秒量级（与现有 CT 日志行为一致），可以迅速获得一张「独立证书」（standalone certificate，体积较大但功能完整）；而真正小巧的「路标相对证书」（landmark-relative certificate）则需要等待下一个路标周期——计划中短期证书每小时一次，长期证书每4小时一次。

用户 agwa 则指出了MTC的另一个系统性挑战：非浏览器的 TLS 客户端（如 curl）缺乏明确的路标分发服务运营方，可能长期无法享受小体积证书的优势，最终导致大型独立证书在浏览器与 CDN 以外的场景中大行其道。

对普通用户意味着什么？

Let's Encrypt 明确表示：现有证书不受影响，续期流程不变。后量子证书推出后，将以一贯的方式提供：免费、自动化、对所有 ACME 客户端开放。

对于服务器运营者，Let's Encrypt 在文章末尾给出了一条当下可立即行动的建议：确保服务器支持 混合后量子密钥交换（X25519MLKEM768）。主流浏览器和操作系统已经支持，这是目前性价比最高的单一安全提升措施。

对于 ACME 客户端维护者，现在是开始跟进 PLANTS 工作组标准进展的好时机——部分变更将要求客户端侧的适配。

小结

这份路线图的意义，不仅在于 Let's Encrypt 自身的技术演进，更在于它代表着 Web PKI 生态正式承认：后量子身份认证的窗口期，比我们想象的更短。Merkle Tree Certificates 的思路优雅地绕开了后量子签名的体积瓶颈，同时将证书透明度从外挂附件变为内生属性。

当然，标准仍在成形，浏览器、库、ACME 客户端的生态适配尚需时日。这不是终点，而是一场历时数年的接力赛刚刚鸣枪。