本文永久链接 – https://tonybai.com/2026/06/10/lets-encrypt-adopts-mtcs-preparing-for-post-quantum-security
大家好，我是Tony Bai。
当你在浏览器地址栏看到那把绿色的小锁，或是敲下 https:// 时，你正在被人类历史上最伟大的密码学基础设施——Web PKI（公钥基础设施）保护着。
长久以来，这套系统的基石是 RSA 和 ECDSA 签名算法。它们精巧、高效，扛住了互联网过去几十年的爆炸式增长。然而，一场风暴正在逼近。
随着量子计算机的发展，悬在所有密码学家头顶的“达摩克利斯之剑”——CRQC（密码学相关的量子计算机），其倒计时正在被各大科技巨头疯狂拨快。
近日，全球最大的免费 HTTPS 证书颁发机构 Let’s Encrypt 发布了一篇声明：《Let’s Encrypt 的后量子未来》。在这份声明中，Let’s Encrypt 不仅拉响了后量子时代的警报，更抛出了一个足以重塑整个互联网底层通信逻辑的终极杀手锏：MTCs（Merkle Tree Certificates，默克尔树证书）。
为什么传统的 RSA 和 ECDSA 会被淘汰？为什么直接换上标准的后量子算法会导致整个互联网“网速倒退”？今天，我们就来深度硬核拆解 Let’s Encrypt 这场惊心动魄的“后量子求生战”。
在讨论后量子密码学（Post-Quantum Cryptography, PQC）时，我们通常要区分两个概念：加密（Encryption / 密钥交换）和认证（Authentication / 签名）。
过去几年，业界对后量子“加密”极为焦虑。原因很简单：“现在收集，以后解密（Harvest now, decrypt later）”。攻击者现在就可以把你加密的流量存进硬盘，等 10 年后量子计算机成熟了，再拿出来暴力破解。因此，像 Google、Cloudflare 这样的巨头早已在各大浏览器和服务器中部署了混合后量子密钥交换算法（如 X25519MLKEM768）。
相比之下，“认证”似乎没那么紧迫。
因为证书签名的作用是证明“我是我”。要伪造一个服务器身份，量子计算机必须在 TLS 握手的几百毫秒内实时（in real time）伪造出一个签名，而不能“事后追溯”。因此，大家都觉得，只要 CRQC 还没造出来，签名就是安全的。
但这种安全感正在被撕裂。
警报拉响了，留给 Web PKI 生态转身的时间，已经从“未来某天”缩短到了“迫在眉睫”。
面对量子威胁，最直接的思路就是：既然 RSA 和 ECDSA 不顶用了，咱们直接把它们替换成 NIST（美国国家标准与技术研究院）最新发布的后量子标准算法 ML-DSA 不就行了吗？
答案是：不行！因为太胖了。
Web PKI 是全球部署环境最复杂的系统之一。在一次典型的 TLS 握手（就是你建立 HTTPS 连接的那一瞬间）中，服务器需要向你的浏览器发送大概 5 个签名和 2 个公钥。
让我们来看看这场“体积灾难”的对比（参考官方给出的图表）：
如果我们在现有的 Web PKI 架构下，简单粗暴地把所有的 ECDSA 替换成 ML-DSA，那么单次 TLS 握手的数据量将直接突破 10 KB（10,000 字节）大关！
这会带来什么毁灭性的后果？
Cloudflare 的硬核研究表明，当 TLS 握手体积膨胀到这个规模时，由于 TCP 拥塞窗口机制和网络 MTU 的限制，大量真实世界的网络连接将直接失败（Fail），而幸存下来的连接也会遭遇严重的延迟。
试想一下，全球数十亿台低带宽的物联网设备、偏远地区的手机，在每一次发起 HTTPS 请求时都要被迫下载十几 KB 的“肥胖”证书。这种为了“防御一个尚未出现的威胁”而牺牲全人类网络体验的做法，在工程上是绝对不可接受的默认设定。
在绝望之中，Let’s Encrypt 和一众硅谷巨头找到了一个极其优雅且疯狂的解法——Merkle Tree Certificates（MTCs）。
这个机制不仅解决了签名体积过大的问题，还顺手重塑了证书透明度（Certificate Transparency, CT）的底层逻辑。
在现有的 Web PKI 中，CA（证书颁发机构）在签发证书时，会对每一张证书单独进行一次签名。
而 MTCs 彻底颠覆了这个逻辑：
CA 不再对单个证书签名，而是把一段时间内（比如一个小时）要签发的所有证书，收集起来构建成一棵 Merkle Tree（默克尔树）。然后，CA 只需要用后量子算法（如 ML-DSA），对这棵树的树根（Root）进行一次唯一的签名。
既然没有单独的签名了，你的浏览器怎么知道你访问的网站证书是合法的呢？
这里利用了默克尔树的密码学奇迹——包含证明（Inclusion Proof）。
浏览器（或客户端）会在后台定期更新 CA 发布的“树根”信息（被称为 Landmarks）。当浏览器访问服务器时，服务器只需要提供一条从自己这片“叶子”走到“树根”的路径（包含证明）。
因为哈希算法生成的包含证明（如 SHA-256）体积非常小（通常只有几百字节），所以在这种常见情况（Common Case）下，一次 TLS 握手的认证数据：
1 个短小精悍的包含证明 + 1 个公钥 + 0 个笨重的后量子签名！
在传统的 PQ（后量子）架构下，开销高达 7,260 字节；而采用了 MTCs 后，瞬间被压缩到了 736 字节，性能甚至直逼现有的传统算法。
这个体积甚至比今天基于 RSA/ECDSA 的传统握手还要小！这种从“胖子”变“瘦子”的降维打击，正是 MTCs 被奉为救星的根本原因。
现有的证书生态里，证书透明度（CT Logs）是一个事后缝合的“补丁”：CA 签发证书后，需要把它记录到一个单独的 append-only 日志系统中，并把签名附在握手数据里。
但在 MTCs 的世界里，“这棵默克尔树本身，就是那个追加日志（Append-only Tree）”！
由于每一张证书都必须存在于默克尔树中才能生效，这意味着没有任何一张 MTCs 证书可以脱离监控而秘密存在。CT 机制被完美、原生在地融入了底层协议中。
这对于 Let’s Encrypt 来说可谓是得心应手，因为他们自 2019 年以来就一直在维护基于底层树数据结构的 CT 日志，技术储备早已拉满。
Let’s Encrypt 宣布，他们正计划在 2026 年末提供 MTCs 的测试环境（Staging），并在 2027 年正式推向生产环境（Production）。
这是 Web PKI 历史上一次规模浩大的“基础设施更换手术”。作为开发者和系统运维人员，这几个关键点你必须立刻了解：
作为服务器的运营者，你现在必须立刻行动：检查你的 Web 服务器（如 Nginx, Envoy, Caddy等）和操作系统配置，确保已经开启了混合后量子密钥交换（如 X25519MLKEM768）。 所有的主流浏览器现在都已经支持它，这是你今天能做的 ROI 最高的安全升级！
从 2013 年 Let’s Encrypt 创立至今，他们始终秉持着一个信念：安全应该是全球每个人都能平等获取的基础权利。
从推动全网 HTTPS 普及，到如今在量子威胁的阴影下，不惜重构庞大底层架构以推行 MTCs，这场无声的战役，不仅是算力与算法的博弈，更是人类为了守护数字世界的信任基石，所进行的一次史诗级防守反击。
达摩克利斯之剑已经落下，但得益于这些密码学极客的疯狂努力，当风暴真正来临的那一天，我们浏览器的左上角，那把绿色的小锁，依然会坚定地亮起。
资料链接：https://letsencrypt.org/2026/06/03/pq-certs
今日开放讨论：
当 MTCs（默克尔树证书）将证书透明度（CT）彻底融入底层结构时，你认为它会对现有的防火墙流量审计（如企业内网对 TLS 的中间人解密审计）带来哪些阻碍和变化？
欢迎在评论区分享你的安全架构洞察，我们一起探讨后量子时代的网络防线建设！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
Related posts:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。