利用 AI 为我们的后量子迁移规划路线
当世界各地的实验室竞相构建与密码学相关的量子计算机时，我们 Cloudflare 也正朝着
2029 年全面后量子就绪的目标截止日期迁移到了后量子加密，但要支持
产品并在我们的平台上实现全面的后量子就绪，我们仍有工作要做。
__后量子认证__我们采取最大化的立场（“一切皆后量子！”），因为作为面向全球的基础设施提供商，我们希望让客户安心：使用 Cloudflare 可确保他们的流量能够抵御未来的量子对手。
但是，在我们这样规模和体量的组织中，如何完成如此大规模的迁移呢？毕竟，密码学几乎是世界上所有数字系统的基础层，包括为我们的平台提供支持的软件服务和网络协议。
为了推动我们的后量子迁移，我们有三个关键目标。
首先，我们希望帮助我们的产品和工程团队了解密码学是如何被使用的，以及他们应如何对其进行升级。这应涵盖后量子加密和后量子认证两方面的升级。我们的许多产品已经在
TLS
后量子加密升级，但我们仍希望覆盖 TLS 连接的长尾部分，并升级任何其他使用公钥加密的地方。与此同时，我们的后量子认证部署仍处于
早期阶段。
其次，我们希望提供迁移的进度指标。这些指标可能包括按代码仓库和按产品统计的经典密码学与后量子密码学的使用数量。
最后，我们希望尽早发现前置条件。如果我们的产品或平台依赖的协议尚未有后量子迁移计划（原因可能是该系统的后量子变体尚未被考虑、后量子标准尚不存在或缺乏共识，或者软件库或其他关键生态系统组件尚不支持后量子），那么我们需要现在就知道。这样，我们就能与相关利益相关方、标准组织和生态系统合作，帮助推动他们的后量子迁移计划，从而让我们能够赶上自己的 2029 年后量子迁移时间表。
这篇文章讲述的就是我们如何做到这一点。我们解释了我们如何借助 AI 来帮助解决一些问题，以及我们如何开发一个名为 CryptoLabe 的内部工具来帮助我们。CryptoLabe 以航海家的星盘命名，这是一种由葡萄牙航海家改进的导航仪器。正如星盘帮助水手确定自己的位置并规划航线一样，CryptoLabe 帮助我们发现代码中的密码学、理解其使用方式，并规划一条通往后量子迁移的道路。
CryptoLabe 高度专用于我们的内部系统（我们的代码仓库、工单系统和内部文档流程），并且随着我们持续开发而仍在演进，因此我们不会将其提供给客户。尽管如此，我们仍分享我们的经验，以便其他组织在开展自己的后量子迁移之旅时能够基于我们的努力继续前进。
问题的规模
支撑大多数 Cloudflare 产品的软件都存在于我们单一的集中式源代码管理平台中。这意味着我们只需查看代码库，就能找到平台上大多数加密技术的使用情况。
虽然代码库的集中化对我们来说是一个显著优势，但我们仍需应对这一问题规模带来的三个挑战。首先，我们的代码分布在许多代码仓库中。其次，加密技术很少在代码中直接表明自身。相反，它隐藏在
- 仓库导入但可能实际调用也可能不调用的共享库中
- 上游和协议默认值中，例如一个 TLS 1.3 监听器被配置为协商经典密钥交换（如 X25519）而非后量子 X25519MLKEM768
- 配置文件中，这些文件选择的算法远离使用它们的代码，例如一个 TLS 响应方的密钥交换协议被固定在一个存储于不同仓库的 YAML 文件中
- 已废弃、仅用于测试或即将弃用的代码路径中
第三，加密技术的发现不仅仅是模式匹配。对某些算法名称（例如“RSA”或“X25519”）进行 grep 会过度计数，因为它会在未使用的代码中找到加密技术。grep 也会计数不足，因为它会遗漏依赖项和配置中的默认值和间接使用。最重要的是，它无法告诉你加密技术是如何被使用的。一个经典的 ECDSA 签名可能是
JWT,
IPsec, 或
TLS, 的一部分，而每种都有完全不同的迁移路径。许多使用还取决于连接的另一端：一个 TLS 服务器可能同时支持后量子密钥交换和经典密钥交换；它选择使用哪一种将取决于客户端。
SSH## 转向 AI
事实证明，AI 不仅擅长 grep，还能做更多事情。模型可以搜索代码库，跨文件追踪证据，并返回结构化分析。它还可以通过从其他来源（如我们的内部文档和工单系统）提取信息来丰富发现结果。事实上，AI 甚至可以解释加密技术是如何被使用的以及应如何更新。我们在开发 CryptoLabe 的过程中一直在测试这一想法。
如前所述，我们的前两个目标是 (1) 发现并理解代码库中加密技术的使用情况，以及 (2) 获取有关我们后量子迁移状态的指标。为实现这些目标，我们当前实现的 CryptoLabe 分两个阶段执行扫描，如下图所示。
第一个“发现”阶段从映射代码仓库开始。然后通过源代码、配置、清单文件、锁文件、脚本、测试和文档来搜索密码学相关的内容。除此之外，扫描还会查找密钥协商、签名、非对称加密、PKI、令牌、凭证、硬件安全模块集成等密码学的使用情况。这个发现阶段会产生一组“原始观察结果”。
每个原始观察结果都会输入到第二阶段的运行中。这个“分析”阶段首先会对照源代码重新检查观察结果。然后调查密码学操作在运行时是如何使用的、该仓库扮演什么角色，以及它依赖哪些内部或外部方。必要时，它可以检查其他仓库中的相关代码以完成分析。最后，它会审查自己的结论，查找缺失或相互矛盾的证据，例如配置覆盖、仅用于测试的代码，或关于运行时行为的不正确假设。
接下来，模型会为该发现分配一个分类。如果没有足够的证据来分配分类，模型会分配需要更多证据、外部依赖或未知，而不是进行猜测。
这是 CryptoLabe 当前使用的分类列表，其中包含一些笼统的分类器，随着我们迁移的推进，这些分类器可能会被细化。（例如，我们可以通过将“加密”分类器拆分为密钥协商和
HPKE
经典加密 | 这是一个笼统的类别，用于发现椭圆曲线的情况
经典签名 | 这是一个笼统的类别，用于发现任何地方使用 RSA 签名或椭圆曲线（ECDSA）签名的情况，例如证书、TLS 握手、其他协议握手。这些签名会被 Shor 算法破解。 |
经典令牌 | 我们发现了许多 |
抗量子就绪的混合密钥交换 | 发现 TLS 1.3 中的混合后量子密钥交换，即 |
抗量子就绪 | 发现后量子密码学的其他用途，这些用途并非 |
最后，它会生成一份报告，服务于两类受众：（1）需要了解迁移对其产品意味着什么的产品经理，以及（2）需要足够细节来执行迁移的工程师。
以下是我们其中一份报告的（裁剪）视图：
虽然我们一直在对照源代码并与相关工程师一起迭代审查发现结果，但我们还没有一个基准数据集，用于可复现地比较我们为 CryptoLabe 尝试过的不同版本的提示词。
构建在 Cloudflare 的开发者平台上
我们在 Cloudflare 的开发者平台上构建了 CryptoLabe。以下是架构：
CryptoLabe 运行在两个 Cloudflare Workers 上。有一个运行扫描的扫描器 Worker。还有一个清单 Worker，它提供仪表板、暴露 API，并将所有内容存储在
数据库中。两者通过进行通信
D1. 当有人从仪表板请求扫描时，扫描就会启动，然后清单 Worker 将请求传递给扫描器。
服务绑定### 编排一次扫描
我们需要一种方法，让扫描从开始到结束始终保持存活并处于正轨，而不必构建自己的作业编排系统。我们通过 Agents SDK 实现了这一点。每个仓库都会获得自己的持久协调器，它构建在
。协调器前面的有界队列限制了同时运行的扫描数量。当某个扫描轮到执行时，协调器会跟踪其进度，并处理取消、重试和恢复。
__Durable Object (DO)__协调器本身并不进行分析。它将工作交给 Cloudflare Workflows，以便它们能够持久化进度并自动重试失败的步骤。协调器让每个仓库经历四个阶段：
- discovery Workflow（第一个扫描阶段，生成原始观察结果）
- deep analysis Workflow（第二个阶段，针对每个原始观察结果运行）
- merge Workflow（为给定仓库构建发现列表，包括合并重复或相似的发现）
- publish workflow（将结果交回给清单 Worker）
前两个工作流需要模型能够访问仓库的代码。我们希望这种访问是隔离的，这样就不会有损坏代码库的风险。因此，CryptoLabe 在每次扫描开始时，会按确切的提交下载一次仓库，然后将该快照存储在 R2 中。随后，每个 Workflow 都会将快照恢复到全新的、短生命周期的
，即一个隔离容器中。然后，模型通过一小组只读工具，在代码的不可变快照上与 Sandbox 协作，即使代码库在扫描仍在运行时发生变化也是如此。
Cloudflare Sandbox### 大规模调用模型
如果我们想要扫描我们所有的（很多！）仓库，就必须同时考虑成本和容量。
在成本方面，模型循环通过 AI Gateway 将其请求发送到托管在
上的高性价比开放权重模型。将模型置于 AI Gateway 之后，也使得在出现更好或更便宜的模型时更容易切换。
__Workers AI__当我们同时扫描许多仓库时，容量就成了问题。模型请求的突发开始触发 AI Gateway 返回 HTTP 429（速率限制）响应，而扫描各自独立重试只会让突发更严重。我们用一个单一的全局 Durable Object 解决了这个问题，它为所有扫描中的每个模型请求（包括重试）控制节奏。当任何扫描遇到速率限制时，冷却时间会被共享，所有扫描一起退避，因此并发扫描会共享可用容量，而不是相互竞争。
先决条件与困难情况
现在让我们进入第三个目标：尽早暴露先决条件和困难情况。
关于后量子（PQ）迁移的生态系统就绪度，已经有很多讨论，现在我们还要再添一些。众所周知，后量子迁移不可能在真空中发生。迁移要成功，后量子密码学必须在相关软件库（例如 BoringSSL）以及参与生态系统的各方（例如客户端、浏览器、源站、云代理、证书颁发机构等）中得到支持。标准也是生态系统支持度的一个重要指标，尽管仍处于“草案”状态的标准并不一定意味着无法推进部署。举个例子，我们早在 2022 年就在 TLS 1.3 中部署了 X25519MLKEM768，当时它还是互联网工程任务组（IETF）的“草案”，而它直到
__RFC 10024__无论如何，我们的观点是：要将系统升级到后量子密码学，我们需要了解其依赖关系和生态系统支持程度。
这就是为什么 CryptoLabe 使用“前置条件”这一概念来突出那些无法由单个产品团队独立立即修复的发现。
前置条件可以像“我们目前被阻塞在迁移到后量子 JWT 上”这样直截了当。我们说它直截了当，是因为后量子 JWT 已经有了标准（RFC 9964）。然而，如果我们的软件库尚不支持验证后量子 JWT，或者我们使用的令牌颁发者尚未颁发后量子 JWT，我们就无法在全公司范围内要求每个产品团队开始将他们的 JWT 后量子化。在解决其核心前置条件之前，这一迁移是被阻塞的。CryptoLabe 让我们能够将（很可能）具有相同前置条件的发现归为一组，这也有助于我们决定如何优先解决这些前置条件。
例如，下面的快照显示了 CryptoLabe 中六个以后量子 SAML 为前置条件的发现。（SAML 是一种用于单点登录（
SSO
另一方面，有些密码学用途甚至缺乏基本的生态系统支持。我们一直称这些为“困难案例”。为了找到它们，我们编写了一个单独的提示词，它忽略密码学的“常规”用途（例如内部系统之间的普通 TLS），转而寻找在大小受限字段中使用的自定义密码协议、密钥或签名、内置于硬件中的密码学、专门的密码构造（如盲签名）、没有后量子标准的协议，以及对尚不支持后量子密码学的外部方的依赖。
这个提示词比用于 CryptoLabe 的提示词更短、更简单，因为它的唯一任务就是找到困难案例。在我们的定性审查中，我们发现当它一次性针对我们所有仓库运行，同时吸收来自我们内部工单和文档系统的上下文时，能取得更好的结果。
以下是我们发现的一个“困难案例”示例：一个携带在 HTTP 头中的证书。后量子证书和签名比经典证书和签名更大，因此如果该头（或中间层，或处理该头的应用程序）假定证书具有特定大小，那么更改签名算法可能会破坏系统。我们的下一步是确定这段代码是否会长期继续使用。如果会，我们就需要测量相关的大小限制，并决定如何容纳更大的证书。
这里的一个重要教训是，没有任何单一扫描能发现所有问题。我们逐个仓库的扫描在发现密码学的常见用途方面很有效。与此同时，这种有针对性的扫描对“困难案例”效果更好，因为它忽略了已被充分理解的密码学，并且对每个产品及其依赖项有更多的上下文信息。
归根结底，不同的方法会发现不同的问题，而每一项发现仍然需要由了解系统实际运作方式的工程师来核查。
分享我们的提示词
过去几个月里，我们一直在尝试为 CryptoLabe 编写提示词的最佳方式。我们目前还没有一个基准数据集来比较一个提示词与另一个提示词的表现，我们也不确信自己已经 100% 覆盖了代码库中所有密码学的使用。相反，我们是通过运行扫描、与维护这些仓库的工程师一起审查发现、调查这些审查过程中出现的遗漏并修订提示词来迭代的。尽管如此，我们还是决定发布部分提示词，以便其他团队可以从中学习并调整我们的方法。这些提示词只是起点，并不是 CryptoLabe 的独立版本，其结果的 quality 将取决于可用的模型、工具、上下文和工程审查。
思考你自己的 PQ 迁移
在 Cloudflare，我们对 PQ 迁移采取最大化的方式，因为我们的目标是充当面向客户和整个互联网的后量子密码学提供者。但大多数组织并不需要从查找其每个产品中每个仓库里每一处密码学使用开始。事实上，大多数组织不应该这样做，因为在当前，这是对宝贵资源的浪费。
在扫描哪怕一个仓库之前，你可以尽可能大规模地保护流量。如果你的网站通过 Cloudflare 运行，我们如今已经使用后量子加密保护你的传输中数据；可以通过我们的
新的 PQ 可见性功能平台，
Cloudflare One提供，并且不需要你升级企业网络上的每一台源服务器或私有应用程序。这在你逐步发现和理解自己系统内部密码学使用的过程中，为你提供了一种补偿性控制。
无额外成本 详尽的密码学资产清单并非行动的前提。相反，组织应首先识别那些一旦被攻破影响最大的系统，发现其密码学使用情况，然后按优先级顺序对这些密码学进行后量子（PQ）升级。以下是一种开始的方法：
为一个重要系统选择一个代码仓库。 从处理敏感或长期数据、对用户或软件进行身份验证，或暴露于公共互联网的系统开始。对该仓库运行密码学发现。 我们希望我们对 CryptoLabe 的描述能对此有所帮助！验证结果。 请拥有该系统的团队验证密码学发现的结果，并确认该密码学发现是长期需要的，且需要升级到 PQ。重要的是要记住，如果存在其他补偿性控制措施，可能不需要立即升级到 PQ。优先处理行动。 弄清楚现在可以进行哪些升级，哪些升级被阻塞。记录需要库、供应商、标准组织或组织内其他部门帮助的共享前提条件。对发现进行优先级排序，并制定计划，首先处理影响最大的系统和前提条件。
这样你就有了 PQ 过渡计划的起点，而无需组织内每个密码学操作的完整映射。CryptoLabe 仍在不断发展，但在我们规划迁移时，它的扫描和结果对我们很有启发。我们希望这些共享的经验教训在你继续自己的 PQ 迁移过程中能有所帮助。
*致谢：Cloudflare 的许多人为 CryptoLabe 提供了反馈和贡献，包括 Davide Marquês、Peter Wu、Phil Schmieder、JP Aumasson、Andrew Galloni、Christopher Patton、Luke Valenta、Mari Galicer、Vânia Gonçalves，以及 *
Client、Tunnel 和
Gateway 团队，他们审查了该工具生成的报告。