A Post-Quantum Future for Let’s Encrypt

Let’s Encrypt 的后量子未来

Let’s Encrypt is committed to a post-quantum-safe Web PKI. The path we’re planning to take is Merkle Tree Certificates (“MTCs”), a new approach that adds post-quantum authentication to the web without sacrificing the speed and reliability that have made TLS universal. This post is about these plans and why we believe MTCs are worth pursuing as a key to a post-quantum future.

Let’s Encrypt 致力于构建一个后量子安全的 Web PKI（公钥基础设施）。我们计划采用的路径是默克尔树证书（Merkle Tree Certificates，简称“MTCs”）。这是一种全新的方法，它在为网络增加后量子身份验证的同时，不会牺牲 TLS 普及所依赖的速度和可靠性。本文将介绍这些计划，以及为什么我们认为 MTC 是通往后量子未来的关键，值得我们去追求。

An increasingly urgent problem

一个日益紧迫的问题

For much of the last several years, the conversation about post-quantum cryptography has been a conversation about encryption. The reasoning was straightforward: an attacker who records encrypted traffic today might be able to decrypt it years from now once quantum computers can break the underlying math. Authentication, the part of TLS that indicates a server is who it says it is, has been a less urgent problem. A quantum computer needs to forge a signature in real time, not retroactively, so threats to authentication hinge on the existence of a cryptographically relevant quantum computer (CRQC).

在过去几年的大部分时间里，关于后量子密码学的讨论主要集中在加密上。其逻辑很简单：攻击者今天记录的加密流量，未来一旦量子计算机能够破解其底层数学原理，就可能被解密。而身份验证（TLS 中用于证明服务器身份的部分）则是一个没那么紧迫的问题。量子计算机需要实时伪造签名，而不是事后追溯，因此对身份验证的威胁取决于“密码学相关量子计算机”（CRQC）的出现。

That comfort has been eroding for a while. In the United States, the NSA’s CNSA 2.0 suite has directed national security systems toward post-quantum algorithms on a 2030-to-2035 schedule since 2022, and NIST’s draft transition guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035. The European Union’s roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. These mandates don’t bind the public Web PKI directly, but they set the end-of-decade timeline that the vendors, libraries, and standards bodies it relies on are already working toward.

这种安稳感早已开始动摇。在美国，自 2022 年起，NSA 的 CNSA 2.0 套件已指导国家安全系统在 2030 年至 2035 年间转向后量子算法；NIST 的过渡指南草案也计划在 2030 年后弃用 RSA-2048 和 P-256，并于 2035 年后彻底禁用。欧盟的路线图则设定在 2030 年底前覆盖高风险系统，并在 2035 年前实现广泛迁移。这些指令虽然不直接约束公共 Web PKI，但它们设定了本世纪末的时间表，而 Web PKI 所依赖的供应商、库和标准机构已经在朝着这个目标努力。

This year, the timeline shortened further. Google announced that it would migrate its services by 2029, citing tightening estimates for the potential arrival of a CRQC. Cloudflare followed with a parallel commitment. In addition, Go 1.27 adds ML-DSA, a NIST-standardized post-quantum signature scheme, to the standard library, a sign that post-quantum signatures are becoming practical infrastructure. Post-quantum authentication is no longer a problem the Web PKI ecosystem should defer. Long-lived keys (root certificate authorities, code-signing keys, identity systems) are particularly valuable targets, and new technology takes years to gain broad adoption, so the work has to start early.

今年，这一时间表进一步缩短。谷歌宣布将在 2029 年前迁移其服务，理由是对 CRQC 可能出现的时间估计变得更加紧迫。Cloudflare 也紧随其后做出了同样的承诺。此外，Go 1.27 在标准库中加入了 NIST 标准化的后量子签名方案 ML-DSA，这标志着后量子签名正成为实用的基础设施。后量子身份验证不再是 Web PKI 生态系统可以推迟解决的问题。长效密钥（根证书颁发机构、代码签名密钥、身份系统）是特别有价值的攻击目标，而新技术的广泛采用需要数年时间，因此工作必须尽早开始。

The Web PKI’s unique circumstances

Web PKI 的特殊情况

The Web PKI is one of the trickiest places to deploy post-quantum signatures. The reason is size. ML-DSA-44, one of the smaller NIST standardized post-quantum signature schemes, has a signature roughly 2,420 bytes long. The algorithms used in the Web PKI today are much smaller. RSA-2048 signatures are 256 bytes and ECDSA-P256 signatures are 64 bytes. Public keys are bigger as well: 1,312 bytes for ML-DSA-44, 256 bytes for RSA-2048, and 64 bytes for ECDSA-P256.

Web PKI 是部署后量子签名最棘手的领域之一。原因在于体积。ML-DSA-44 是 NIST 标准化后量子签名方案中较小的一种，其签名长度约为 2,420 字节。而目前 Web PKI 使用的算法要小得多：RSA-2048 签名仅为 256 字节，ECDSA-P256 签名仅为 64 字节。公钥也同样更大：ML-DSA-44 为 1,312 字节，而 RSA-2048 为 256 字节，ECDSA-P256 为 64 字节。

A typical Web PKI handshake today carries five signatures and two public keys. Replacing those with ML-DSA equivalents would push a single TLS handshake well past 10 kilobytes. Cloudflare’s research has shown that, at that scale, a meaningful share of TLS connections fail on real-world networks, and the rest get slower. Larger handshakes would affect every TLS connection, not just those that would fail. They would mean constrained bandwidth, slower connections, and a worse experience for users, all in exchange for security against a threat that hasn’t materialized yet. That’s a steep cost to enable by default, and defaults are what actually move security at web scale.

目前典型的 Web PKI 握手包含五个签名和两个公钥。如果用 ML-DSA 等效项替换它们，单次 TLS 握手的数据量将远超 10 KB。Cloudflare 的研究表明，在这种规模下，现实网络中会有相当大比例的 TLS 连接失败，其余连接也会变慢。更大的握手数据包会影响每一个 TLS 连接，而不仅仅是那些失败的连接。这意味着带宽受限、连接变慢以及用户体验下降，而这一切仅仅是为了防范一个尚未出现的威胁。作为默认配置，这个代价太高了，而默认配置才是真正推动网络规模安全的关键。

Merkle Tree Certificates

默克尔树证书 (MTCs)

A different design called Merkle Tree Certificates (“MTCs”) has been emerging over the past year, and we believe it is a strong path forward for the post-quantum Web PKI. Instead of issuing certificates one at a time and signing each one individually, an MTC certificate authority issues certificates in batches, with a single signature covering the entire batch. Browsers stay up to date on those batch signatures (called “landmarks”) separately from the TLS handshake.

过去一年中，一种名为“默克尔树证书”（MTCs）的新设计逐渐兴起，我们认为这是后量子 Web PKI 的一条有力发展路径。MTC 证书颁发机构不再逐个签发证书并对每个证书单独签名，而是以批次形式签发，并用一个签名覆盖整个批次。浏览器则在 TLS 握手之外，独立更新这些批次签名（称为“地标”/landmarks）。

In the common case, the entire authentication path in an MTC handshake is one signature, one public key, and one inclusion proof. That’s smaller than today’s Web PKI handshake, even though MTCs use post-quantum algorithms. The other case is the “standalone” form. It uses slightly larger handshakes as a fallback when a client’s landmark is out of date.

在通常情况下，MTC 握手中的整个身份验证路径仅包含一个签名、一个公钥和一个包含证明。尽管 MTC 使用了后量子算法，但其体积仍比当前的 Web PKI 握手更小。另一种情况是“独立”形式，当客户端的“地标”过期时，它会作为回退方案使用稍大的握手数据包。

There is more to MTCs than size optimization. Because every certificate is part of a published Merkle tree, transparency becomes a property of issuance itself. Today’s Certificate Transparency ecosystem is bolted on after the fact: certificates are issued by CAs, then logged separately, with extra signatures riding along in the TLS handshake to attest to that logging. With MTCs, a certificate cannot exist outside the Merkle tree. Certificate Transparency is built in.

MTC 的意义不仅在于体积优化。由于每个证书都是已发布默克尔树的一部分，透明度成为了签发过程本身的固有属性。当前的证书透明度（Certificate Transparency）生态系统是事后附加的：证书由 CA 签发，然后单独记录，并在 TLS 握手中携带额外签名以证明该记录。而有了 MTC，证书不可能存在于默克尔树之外。证书透明度是内置的。

This is not entirely new ground for us. Let’s Encrypt has operated Certificate Transparency logs since 2019. Those logs are append-only Merkle trees, the same core data structure MTCs are built on, and ones we have run in production, at scale, for years. Cloudflare and Chrome are already running a feasibility experiment with MTCs against real internet traffic. The IETF’s PLANTS working group is working on standardizing the design. Chrome has announced that MTCs are its preferred path for adding post-quantum certificates to the public web.

这对我们来说并非完全陌生的领域。Let’s Encrypt 自 2019 年以来一直在运营证书透明度日志。这些日志就是只读的默克尔树，这正是 MTC 构建所依赖的核心数据结构，我们已经在生产环境中大规模运行了多年。Cloudflare 和 Chrome 已经在针对真实互联网流量进行 MTC 的可行性实验。IETF 的 PLANTS 工作组正在致力于该设计的标准化。Chrome 也已宣布，MTC 是其为公共网络添加后量子证书的首选路径。

Our plans

我们的计划

We are planning to support Merkle Tree Certificates as the path forward for the post-quantum Web PKI. We are targeting late 2026 for a staging environment that issues MTCs, and 2027 for a production-ready environment. This is not a small endeavor. Issuing MTCs at the scale of Let’s Encrypt requires meaningful changes throughout our stack: in our issuance infrastructure, in the ACME protocol our subscribers use to obtain certificates, in revocation and operational tooling, and in the transparency-log infrastructure that MTCs subsume.

我们计划支持默克尔树证书，将其作为后量子 Web PKI 的发展方向。我们的目标是在 2026 年底建立一个签发 MTC 的测试环境，并在 2027 年实现生产就绪。这不是一项小工程。以 Let’s Encrypt 的规模签发 MTC，需要对我们的整个技术栈进行重大调整：包括签发基础设施、用户获取证书所用的 ACME 协议、吊销和运维工具，以及 MTC 所涵盖的透明度日志基础设施。