RSA 将死？Let’s Encrypt 押注 MTCs 迎战后量子时代
本文永久链接 – 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 这场惊心动魄的“后量子求生战”。
倒计时缩短：为什么认证（Authentication）的危机突然爆发了？
在讨论后量子密码学（Post-Quantum Cryptography, PQC）时，我们通常要区分两个概念：加密（Encryption / 密钥交换）和认证（Authentication / 签名）。
过去几年，业界对后量子“加密”极为焦虑。原因很简单：“现在收集，以后解密（Harvest now, decrypt later）”。攻击者现在就可以把你加密的流量存进硬盘，等 10 年后量子计算机成熟了，再拿出来暴力破解。因此，像 Google、Cloudflare 这样的巨头早已在各大浏览器和服务器中部署了混合后量子密钥交换算法（如 X25519MLKEM768）。
相比之下，“认证”似乎没那么紧迫。
因为证书签名的作用是证明“我是我”。要伪造一个服务器身份，量子计算机必须在 TLS 握手的几百毫秒内实时（in real time）伪造出一个签名，而不能“事后追溯”。因此，大家都觉得，只要 CRQC 还没造出来，签名就是安全的。
但这种安全感正在被撕裂。
- 政策强制清退：美国国家安全局（NSA）的 CNSA 2.0 套件明确规定，必须在 2035 年之后全面禁用 RSA-2048 和 P-256。欧盟也出台了类似的路线图。由于各种底层依赖库、根证书的更替周期极长，生态系统实际上已经被逼到了悬崖边。
- 巨头的极限施压：2026 年初，Google 震撼宣布，将在 2029 年之前全面迁移其服务；紧接着 Cloudflare 也做出了同样激进的承诺。Go 语言（1.27 版本）甚至直接将 NIST 标准化的后量子签名算法 ML-DSA 塞进了标准库。
警报拉响了，留给 Web PKI 生态转身的时间，已经从“未来某天”缩短到了“迫在眉睫”。
灾难推演：为什么直接换算法，会让互联网网速倒退？
面对量子威胁，最直接的思路就是：既然 RSA 和 ECDSA 不顶用了，咱们直接把它们替换成 NIST（美国国家标准与技术研究院）最新发布的后量子标准算法 ML-DSA 不就行了吗？
答案是：不行！因为太胖了。
Web PKI 是全球部署环境最复杂的系统之一。在一次典型的 TLS 握手（就是你建立 HTTPS 连接的那一瞬间）中，服务器需要向你的浏览器发送大概 5 个签名和 2 个公钥。
让我们来看看这场“体积灾难”的对比（参考官方给出的图表）：
- 目前的 ECDSA-P256：签名大小仅为 64 字节。公钥只有区区 64 字节。整个握手的认证数据大概只有几百字节。
- 后量子时代的 ML-DSA-44：哪怕是最小的规格，其一个签名的大小也高达 2,420 字节！公钥大小飙升至 1,312 字节！
如果我们在现有的 Web PKI 架构下，简单粗暴地把所有的 ECDSA 替换成 ML-DSA，那么单次 TLS 握手的数据量将直接突破 10 KB（10,000 字节）大关！
这会带来什么毁灭性的后果？
Cloudflare 的硬核研究表明，当 TLS 握手体积膨胀到这个规模时，由于 TCP 拥塞窗口机制和网络 MTU 的限制，大量真实世界的网络连接将直接失败（Fail），而幸存下来的连接也会遭遇严重的延迟。
试想一下，全球数十亿台低带宽的物联网设备、偏远地区的手机，在每一次发起 HTTPS 请求时都要被迫下载十几 KB 的“肥胖”证书。这种为了“防御一个尚未出现的威胁”而牺牲全人类网络体验的做法，在工程上是绝对不可接受的默认设定。
破局杀招：Let’s Encrypt 押注 MTCs（默克尔树证书）
在绝望之中，Let’s Encrypt 和一众硅谷巨头找到了一个极其优雅且疯狂的解法——Merkle Tree Certificates（MTCs）。
这个机制不仅解决了签名体积过大的问题，还顺手重塑了证书透明度（Certificate Transparency, CT）的底层逻辑。
1. 放弃“一人一签”，改用“批量打包”
在现有的 Web PKI 中，CA（证书颁发机构）在签发证书时，会对每一张证书单独进行一次签名。
而 MTCs 彻底颠覆了这个逻辑：
CA 不再对单个证书签名，而是把一段时间内（比如一个小时）要签发的所有证书，收集起来构建成一棵 Merkle Tree（默克尔树）。然后，CA 只需要用后量子算法（如 ML-DSA），对这棵树的树根（Root）进行一次唯一的签名。
2. 浏览器如何验证？
既然没有单独的签名了，你的浏览器怎么知道你访问的网站证书是合法的呢？
这里利用了默克尔树的密码学奇迹——包含证明（Inclusion Proof）。
浏览器（或客户端）会在后台定期更新 CA 发布的“树根”信息（被称为 Landmarks）。当浏览器访问服务器时，服务器只需要提供一条从自己这片“叶子”走到“树根”的路径（包含证明）。
因为哈希算法生成的包含证明（如 SHA-256）体积非常小（通常只有几百字节），所以在这种常见情况（Common Case）下，一次 TLS 握手的认证数据：
1 个短小精悍的包含证明 + 1 个公钥 + 0 个笨重的后量子签名！
在传统的 PQ（后量子）架构下，开销高达 7,260 字节；而采用了 MTCs 后，瞬间被压缩到了 736 字节，性能甚至直逼现有的传统算法。
这个体积甚至比今天基于 RSA/ECDSA 的传统握手还要小！这种从“胖子”变“瘦子”的降维打击，正是 MTCs 被奉为救星的根本原因。
3. 天生自带的“透明度”
现有的证书生态里，证书透明度（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 历史上一次规模浩大的“基础设施更换手术”。作为开发者和系统运维人员，这几个关键点你必须立刻了解：
- 目前不用慌，但要保持关注：今天，你依然可以像以前一样，通过 Let’s Encrypt 免费、自动地续签你现有的 RSA/ECDSA 证书。
- 底层协议正在疯狂博弈：IETF 的 PLANTS 工作组正在紧锣密鼓地制定 MTCs 的标准。如果你维护着类似于 certbot 这样的 ACME 客户端，或者负责底层的证书签发管道，现在是时候去查阅 mtcs@chromium.org 邮件列表并跟进 draft-ietf-tls-mldsa 草案了。
- 不要忘了“加密”危机：虽然 Let’s Encrypt 正在通过 MTCs 解决“认证”问题，但文章结尾发出了严厉警告：后量子“加密（Encryption）”危机是当下最紧急的问题！
作为服务器的运营者，你现在必须立刻行动：检查你的 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》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
- 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
- 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
- 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
- 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
- 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论