抵御未来威胁：Cloudflare 迈入后量子时代

我们日常使用的加密技术会有过时的一天。难以准确预判，但大约 15 到 40 年之间，预计会诞生足够强大的量子计算机，它能够解密当今互联网上的几乎所有加密数据。

幸运的是，有一种解决方案：后量子 (PQ) 加密技术能够抵御量子计算机的威胁。就在三个月前即 2022 年 7 月，历经六年的全球竞争之后，以 AES 和 SHA2 著称的美国国家标准与技术研究院 (NIST) 宣布推出了他们将进行标准化的后量子加密技术。NIST 计划在 2024 年发布最终标准，但我们希望帮助推动及早采用后量子加密技术。

从今天开始，作为测试版服务，通过 Cloudflare 提供的所有网站和 API 都将支持后量子混合密钥协议。此项默认开启¹；无需选择加入。这意味着，如果您的浏览器/应用支持该协议，与我们网络的连接也就能够抵御未来任何量子计算机的威胁。

我们免费提供这种后量子加密技术：我们相信，后量子安全性应当成为互联网的新基准。

随着量子计算机即将来临，部署后量子加密技术的必要性似乎毋庸置疑，但这样做并非没有风险。首先，这是一项新技术：哪怕是经过多年的仔细审查，仍有可能发现灾难性的攻击。正因为如此，我们才部署混合模式：将久经考验的密钥协议与新协议相结合，以增加后量子安全性。

我们主要担心可能看似仅仅是实用性的一些东西。尽管用于保护互联网的协议设计为支持像这样的顺畅过渡，但在现实中，存在许多有漏洞的代码：试图创建后量子安全连接可能因各种原因而失败，例如，中间盒对更大的后量子密钥感到困惑，以及我们尚未观察到的其他原因，因为这些后量子密钥协议是全新的。正是由于这些问题的存在，我们感到很有必要及早部署后量子加密技术，这样我们就能与浏览器和其他客户端一起发现并解决这些问题。

在本博客文章中，我们将介绍用于保护互联网的协议 TLS 如何设计为支持顺畅安全地迁移它所使用的加密技术。接着，我们将探讨我们已部署的后量子加密技术的技术细节，以及这种迁移在实践中可能有多大的难度。在本博客文章末尾，我们会说明您可以如何帮助我们测试这种新一代加密技术，一起打造更好的后量子安全互联网。

当您使用安全连接浏览网站时，无论是使用 HTTP/1.1 还是 QUIC，底层都会使用传输层安全性 (TLS) 协议。有两个 TLS 主版本如今很常用：新的 TLS 1.3（约 90%）和旧的 TLS 1.2（约 10%），后者用得越来越少。

TLS 1.3 相对于 TLS 1.2 是巨大的改进：在合适的方面更快速、更安全、更简单、更灵活。因此，向 TLS 1.3 添加后量子安全性相较于 TLS 1.2 更容易。目前，我们只向 TLS 1.3 添加了后量子支持功能，暂不管 TLS 1.2。

那么，TLS 到底是干什么的呢？其目标就是在浏览器与网站之间设置连接，从而实现

• 保密性和完整性，致使任何人都无法阅读或篡改数据而不被发现。

• 真实性，保证您确信自己连接到了正确的网站，而非假冒网站。

TLS 中使用了三种不同类型的加密技术来实现此目标。

• 对称加密，更确切的名称是使用关联数据的身份验证加密 (AEAD)，它是加密技术的“老黄牛”：它用于确保保密性和完整性。这是一种简单明了的加密：有单个密钥用于加密和解密数据。没有合适的密钥，就无法解密数据，对已加密数据进行任何篡改都会在解密时导致错误。

在 TLS 1.3 中，ChaCha20-Poly1305 和 AES128-GCM 如今很常用。那量子攻击呢？乍一看，我们似乎需要切换到 256 位对称密钥来防御 Grover 算法。然而，在现实中，Grover 算法并不能很好地并行化，因此目前部署的 AEAD 就够用了。

因此，如果我们可以就用于对称加密的共享密钥达成一致，就很有希望了。但如何获取共享密钥呢？总不能挑选一个密钥就发送给服务器吧，那样的话，正在侦听的任何人也会知道该密钥。这项任务看起来似乎无法实现，但这正是非对称加密技术可以大显身手的方面：

• 密钥协议也称为密钥交换或密钥分发，是一种加密协议，其中两方就共享密钥达成一致，而杜绝了第三方窃听到任何信息的可能性。如今，X25519 椭圆曲线 Diffie–Hellman 协议 (ECDH) 是 TLS 1.3 中使用的名副其实的标准密钥协议。X25519 的安全性基于椭圆曲线的离散对数问题，但容易受到量子攻击，因为使用 Shor 算法的加密相关量子计算机能够轻松进行解算。解决方案是使用后量子密钥协议，例如 Kyber。

密钥协议只能防御消极攻击者。而积极攻击者如果拦截并修改了消息 (MitM)，就能与服务器和浏览器分别确立单独的共享密钥，从而重新加密在其中传递的所有数据。要解决该问题，我们需要加密技术的最后一个要素。

• 使用数字签名算法，例如 RSA 或 ECDSA，有两个密钥：一个公钥和一个私钥。只有使用私钥才能创建消息的签名。有对应公钥的任何人都可以检查签名对于给定消息是否确实有效。这些数字签名在用于对网站进行身份验证的 TLS 证书中居于核心地位。RSA 和 ECDSA 都容易受到量子攻击。我们尚未将它们替换为后量子签名。原因是，身份验证不太紧迫：我们只需要在足够大型的量子计算机建造出来时将其替换即可，而当下由有漏洞的密钥协议保护的任何数据都可以存储起来并在未来解密。尽管时间宽裕，但部署后量子身份验证会相当有挑战性。

那么，这些构建块是如何组合起来创建 TLS 的呢？

TLS 1.3 的高度概述

TLS 连接始于握手，后者用于对服务器进行身份验证并派生共享密钥。浏览器（客户端）首先发送一条 ClientHello 消息，其中包含其支持的 AEAD、签名算法和密钥协议方法的列表。为避免往返，客户端可以猜测服务器支持什么，并发送一个或多个客户端密钥共享来开始密钥协议。猜测可能正确（下图左侧），也可能客户端需要重试（右侧）。

已对服务器进行身份验证的 TLS 1.3 的协议流，左侧是支持的客户端密钥共享，右侧是 HelloRetryRequest。

密钥协议

在说明此交互的其余部分之前，我们先来深入研究一下密钥协议：什么是密钥共享？Kyber 和 X25519 密钥协议的工作方式不同：前者是密钥封装机制 (KEM)，而后者是 Diffie–Hellman (DH) 样式的协议。后者更灵活，但对于 TLS 而言并没有区别。

TLS 中 KEM 和 Diffie–Hellman 密钥协议的形状相同。

在两种情况下，客户端都会向服务器发送一个客户端密钥共享。服务器会根据此客户端密钥共享生成共享密钥 ss。接着，服务器会返回一个服务器密钥共享，客户端也可以使用它来计算共享密钥。

返回 TLS 1.3 流：服务器收到 ClientHello 消息时，会提取其支持的 AEAD（密码）、签名算法和客户端密钥共享。它使用 ServerHello 消息来回复，其中包含所选密钥协议的所选 AEAD 和服务器密钥共享。锁定 AEAD 和共享密钥后，服务器开始加密数据（图中涂为绿色）。

身份验证

服务器随 AEAD 和服务器密钥共享一起发送签名（即握手签名），这些会放在目前为止的通信记录中，与用于创建签名的公钥的证书（链）一起保存。这样一来，客户端就可以对服务器进行身份验证：它会检查自己是否信任对公钥进行认证的_证书颁发机构（例如，Let’s Encrypt），以及签名是否验证了它目前为止收发的消息。这不仅会对服务器进行身份验证，还能防御降级攻击。

降级攻击

我们无法同时将所有客户端和服务器升级到后量子加密技术。而是存在一个过渡期，其中只有一些客户端和一些服务器支持后量子加密技术。TLS 1.3 中的密钥协议协商允许出现这种情况：在过渡期间，服务器和客户端仍将支持非后量子密钥协议，并可以根据需要回退到这些协议。

这种灵活性非常好，但也让人害怕：如果客户端和服务器都支持后量子密钥协议，我们想确保它们也协商后量子密钥协议。在 TLS 1.3 中就是这种情况，但并非显而易见：密钥共享、所选密钥共享和支持的密钥协议列表都采用明文发送。有没有可能攻击者在中间去除后量子密钥协议？这称为降级攻击。

此时记录就派上用场了：握手签名是对服务器目前为止收发的所有消息签署的。这包括支持的密钥协议和选取的密钥协议。如果攻击者更改了客户端发送的支持的密钥协议列表，服务器不会注意到。但是，客户端会根据自己实际发送的支持的密钥协议列表检查服务器的握手签名，从而能够检测到篡改行为。

降级攻击问题对于 TLS 1.2 复杂得多，这也是我们不愿在 TLS 1.2 中翻新后量子安全性的原因之一。

结束握手

服务器响应的最后一部分是_“服务器完成的”，是目前为止整个记录上的_消息身份验证代码 (MAC)。这些工作大部分已由握手签名完成，但在没有握手签名的其他 TLS 运行模式（例如会话恢复）中，这很重要。

使用所选 AEAD 和服务器密钥共享，客户端可以计算共享密钥并解密和验证证书链、握手签名和握手 MAC。我们之前没有提到这一点，但共享密钥并未直接用于加密，而是作为额外措施与通信记录混合在一起，从而派生出多个特定密钥以供在握手期间以及后面的主连接期间使用。

客户端发送其自己的握手 MAC，然后继续发送使用握手期间派生的密钥加密的特定于应用程序的数据，才能结束握手。

喂！重试请求？

我们刚才概述的就是一种理想的流程，即客户端发送服务器支持的密钥共享。实际情况可能并非如此。服务器如果不接受客户端公告的任何密钥协议，就会告知客户端并中止连接。

如果有双方都支持的密钥协议，但客户端未针对该协议发送密钥共享，则服务器将使用 HelloRetryRequest (HRR) 消息进行响应，请求客户端支持的特定密钥协议的密钥共享, 如图右侧所示。反过来，客户端会使用带有所选密钥共享的新 ClientHello 进行响应。

这并非事情的全貌：服务器也可以发送 HelloRetryRequest，请求它所偏好的不同密钥协议，而不是客户端为其发送共享的协议。例如，如果客户端支持某后量子密钥协议，但未针对该协议发送密钥共享，则服务器可以将 HelloRetryRequest 发送到该协议。

HelloRetryRequest 如今很罕见。几乎每个服务器都支持 X25519 密钥协议，而且几乎每个客户端（目前的比例高达 98%）都会发送 X25519 密钥共享。早先，P-256 是名副其实的标准，在很长一段时间内，许多浏览器会同时发送 P-256 和 X25519 密钥共享，防止发出 HelloRetryRequest。正如后面要讨论的那样，我们可能无法承受发送两个后量子密钥共享的高昂代价。

理论上是这样

TLS 1.3 设计为能够灵活应对其使用的加密技术中的各种情况，而不会降低安全性或性能，这便于我们迁移到后量子加密技术。理论上是这样，但现实中存在一些严重的问题，我们会在后面详谈。但首先，我们来看一下我们已经部署的后量子密钥协议。

今天，我们启用了对 X25519Kyber512Draft00 和 X25519Kyber768Draft00 密钥协议的支持，使用的分别为 TLS 标识符 0xfe30 和 0xfe31。这些就是我们今年 7 月在有限数量的区域上启用的相同密钥协议。

这两个密钥协议是一种混合协议，将经典的 X25519 分别与新的后量子 Kyber512 和 Kyber768 相结合（按此顺序）。这意味着，如果 Kyber 不安全，连接的安全性仍然与 X25519 等同。

Kyber 目前是 NIST 选择进行标准化的唯一密钥协议。Kyber 要求 CPU 非常轻量：它比以快速著称的 X25519 还要快。另一方面，其密钥共享明显更大：

		密钥共享大小（以字节为单位）		操作次数/秒（越高越好）
算法	PQ	客户端	服务器	客户端	服务器
Kyber512	✅	800	768	50,000	100,000
Kyber768	✅	1,184	1,088	31,000	70,000
X25519	❌	32	32	17,000	17,000

X25519 和 Kyber 之间的大小和 CPU 性能比较。性能在不同硬件平台和实现约束之间的差异非常大，应仅视为粗略参考。

在 NIST 于 2024 年进行最终标准化之前，Kyber 预计会有轻微改动，但这些改动向后不兼容。此外，与 TLS 的集成（包括混合密钥协议的选择与细节）尚未由 TLS 工作组最终确定。最终确定之后，我们会立即加以采用。

有鉴于此，长期来看我们不会支持今天宣布的初步密钥协议；它们是作为测试版服务提供的。我们会在 pq.cloudflareresearch.com 上发布关于我们的部署的更新，并在 IETF PQC 邮寄列表中宣布。

现在我们已经知道 TLS 协商在理论上的运作方式，以及我们要添加哪些密钥协议，那怎么会失败呢？

协议通常在设计时会充分考虑到灵活性，但如果在现实中没有运用灵活性，往往会丧失灵活性。这称为协议僵化。多种僵化情况加大了推出 TLS 1.3 的难度。一个令人感伤的例子是 TLS 的版本协商：在 ClientHello 消息中有一个版本字段，指示客户端支持的最新版本。新版本已分配给 TLS 1.3，但测试结果表明，许多服务器不会正确回退到 TLS 1.2，而是让连接崩溃。我们该如何解决僵化问题呢？

解决办法

如今，TLS 1.3 将自己伪装成 TLS 1.2，在 ClientHello 中包含许多旧版字段。实际版本协商移至消息的新扩展。TLS 1.2 服务器将忽略新扩展，并且不知情地继续使用 TLS 1.2，而 TLS 1.3 服务器会提取扩展并继续使用严格意义上的 TLS 1.3。

协议润滑脂

如何防止僵化？浏览器在从这种经历中获得经验教训后，会在这个新的版本字段中公告虚拟版本，这样就能及早发现行为不良的服务器。这样做不仅是针对新版本字段，还针对 TLS 握手中的其他许多方面，而且还预见性地针对密钥协议标识符。如今，40% 的浏览器会发送两个客户端密钥共享：一个 X25519 和一个虚假的 1 字节密钥共享，用于保持密钥协议灵活性。

此行为在 RFC 8701 中已标准化：生成随机扩展并维持可扩展性 (GREASE)，我们称之为协议润滑，正如 Adam Langley 比喻的那样，协议有关节生锈而需要润滑油来“润滑关节”。

此密钥共享润滑脂会有所助益，但并不完美，因为在此会导致最大担忧的是密钥共享大小。

后量子密钥共享很大。两个 Kyber 混合分别是 832 字节和 1,216 字节。相比较而言，X25519 则很微小，只有 32 字节。一些实现在遇到如此巨大的密钥共享时会失败，这并非不可能。

我们最大的担忧是基于 Kyber768 的更大密钥共享。使用更小的 832 字节基于 Kyber512 的密钥共享的 ClientHello 刚刚好能放入典型的 TCP 数据包中。另一方面，更大的 1,216 字节基于 Kyber768 的密钥共享通常会将 ClientHello 分为两个数据包。

将数据包组合起来是有代价的：您需要跟踪部分消息的去向。通常这是由操作系统的 TCP 堆栈以透明方式执行的，但经优化的中间盒与负载平衡器会单独考虑每个数据包，因此必须（可能不会）自行跟踪连接。

QUIC

HTTP/3 是在 QUIC 基础之上构建的，它的情况特别有意思。客户端不会选择一个简单的端口号（如 TCP 中那样），相反，来自客户端的 QUIC 数据包中包含服务器选择的连接 ID。不妨将其视为传统信件中“您的引用”和“我们的引用”。这样一来，QUIC 负载平衡器就可以将处理连接的特定机器编码为连接 ID。

打开连接时，QUIC 客户端并不知道服务器想要哪个连接 ID，便发送一个随机连接 ID。如果客户端需要多个初始数据包，例如带有大型 ClientHello 的数据包，则客户端将使用相同的随机连接 ID。尽管 QUIC 标准允许存在多个初始数据包，但 QUIC 负载平衡器可能并未预料到这种情况，因而无法引用底层 TCP 连接。

除了这些硬故障之外，性能降级之类的软故障也值得关注：如果加载速度太慢，那么这跟网站一开始就崩溃也没什么两样。

早在 2019 年与 Google 开展的联合实验中，我们就部署了两个后量子密钥协议：基于 NTRU-HRSS 的 CECPQ2 和基于 SIKE 的 CECPQ2b。NTRU-HRSS 非常类似于 Kyber，但更大一些，也更慢一些。2019 年的结果很乐观：X25519+NTRU-HRSS（橙线）与单独的 X25519（蓝线）很难分辨开。

我们将继续密切关注性能，尤其是尾部性能：我们希望所有人都能从互联网上最快的客户端顺畅过渡到最慢的客户端。

互联网是一个高度异构的系统。要找到所有问题，我们需要足够数量的各类测试者。我们与浏览器一起密切合作，添加对这些密钥协议的支持，但可能不是每个网络中都有其中一个浏览器。

因此，为了向互联网提供帮助，请尝试将您的一小部分流量切换到 Cloudflare 域，以使用这些新的密钥协议方法。我们为 BoringSSL、Go 和 quic-go 设立了开源分叉。对于 BoringSSL 和 Go，请查看此处的示例代码。如果您有任何问题，请向 [email protected] 发送邮件告诉我们。我们将在 IETF TLS 工作组层面讨论所有问题和解决办法。

过渡到后量子安全互联网势不容缓，但也存在一些挑战。如今，我们已经在我们的所有服务器（构成互联网中不小的一部分）上部署了初步后量子密钥协议，这样我们大家就可以立即开始测试这场大迁移。我们希望到 2024 年 NIST 最终完成 Kyber 时，我们大家都为顺畅过渡到后量子互联网打好了基础。

.....1只有在基于 TLS 1.3（包括 HTTP/3）的协议中，我们才会支持这些后量子密钥协议。一个例外情况是：目前，我们在 FIPS 模式下禁止交换这些网站的混合密钥。