Cloudflare利用AI规划后量子迁移
Cloudflare AI··作者 Tiago Silva
关键信息
CryptoLabe针对Cloudflare的代码仓库、工单系统和内部文档流程进行了专门设计，因此该公司目前不计划向客户提供这一工具。Cloudflare已通过TLS 1.3在许多产品中部署后量子加密，但仍需处理剩余的TLS连接、其他公钥加密用途，以及成熟度较低的后量子身份认证。
资讯摘要
随着全球实验室继续研发具备密码破解能力的量子计算机，Cloudflare正在推进一项覆盖全公司的计划，目标是在2029年前全面实现后量子就绪。虽然许多Cloudflare产品已经通过TLS 1.3支持后量子加密，但该公司仍需覆盖传统或较少使用的连接、其他公钥加密场景，以及后量子身份认证。其迁移计划有三个主要目标：帮助工程团队理解密码技术的使用方式和升级要求，提供按代码仓库和产品划分的进度指标，并在外部依赖拖延项目之前识别必要条件。这些外部依赖可能包括尚无迁移方案的协议、缺乏共识的标准，以及尚未支持后量子技术的软件库或生态组件。
为管理这项工作，Cloudflare正在构建AI辅助内部工具CryptoLabe，用于发现源代码中的密码技术、判断其具体用途，并帮助团队规划升级路径。集中式源代码管理使大部分代码可以统一搜索，但盘点工作仍然困难，因为代码分布在众多仓库中，而且密码技术可能隐藏在共享库、配置文件、协议默认设置或间接依赖之后。例如，一个TLS 1.3服务仍可能协商传统的X25519密钥交换，而不是后量子的X25519MLKEM768方案。CryptoLabe目前仍是一个持续演进且针对Cloudflare内部环境定制的系统，但该公司正在分享实践经验，以帮助其他组织开展类似迁移。
资讯正文
随着世界各地的实验室竞相打造具备密码学实用价值的量子计算机，Cloudflare 也在争分夺秒，力争于 2029 年的目标期限前全面做好后量子准备。虽然我们已经将许多产品迁移到后量子加密，但要支持后量子身份验证，并让整个平台全面做好后量子准备，我们仍有工作要做。
我们采取的是一种最大化立场（“一切都要后量子化！”），因为作为一家服务全球的基础设施提供商，我们希望让客户安心：使用 Cloudflare，可以确保他们的流量具备抵御未来量子对手的能力。
但对于我们这样规模庞大的组织，该如何完成如此大规模的迁移？毕竟，密码学是全球几乎所有数字系统的基础层，其中包括支撑我们平台的软件服务和网络协议。
为了推动后量子迁移，我们设定了三个关键目标。
首先，我们希望帮助产品和工程团队了解密码学的使用方式，以及应当如何对其进行升级。这既要涵盖向后量子加密的升级，也要涵盖向后量子身份验证的升级。我们的许多产品已经通过 TLS 1.3 升级到后量子加密，但我们仍希望覆盖剩余的长尾 TLS 连接，并升级公钥加密的其他所有应用。与此同时，我们部署后量子身份验证的工作仍处于早期阶段。
其次，我们希望提供衡量迁移进度的指标，其中可能包括按代码仓库和产品统计传统密码学与后量子密码学的使用次数。
最后，我们希望尽早发现前置条件。如果我们的产品或平台所依赖的协议尚无后量子迁移计划——原因可能是尚未考虑系统的后量子变体、后量子标准尚不存在或未形成共识，或者软件库及其他关键生态系统组件尚不支持后量子技术——那么我们现在就需要知道。这样，我们便能与相关利益方、标准组织和生态系统合作，协助推动其后量子迁移计划，从而确保我们能够按自己的时间表，在 2029 年前完成后量子迁移。
本文讲述了我们如何推进这项工作。我们将说明如何借助 AI 解决其中一些问题，以及如何开发一款名为 CryptoLabe 的内部工具来提供帮助。CryptoLabe 以航海星盘命名，这是一种由葡萄牙航海家改进的导航仪器。正如星盘曾帮助水手确定自身位置并规划航线一样，CryptoLabe 可以帮助我们发现代码中的密码学应用、了解其使用方式，并规划后量子迁移路径。
CryptoLabe 针对我们的内部系统进行了高度定制，包括代码仓库、工单系统和内部文档流程；随着开发工作的持续推进，它也仍在不断演变，因此我们不会将其提供给客户。尽管如此，我们仍愿意分享从中获得的经验，以便其他组织在开展自己的后量子迁移之旅时，能够以我们的工作为基础继续前进。
问题的规模
支撑 Cloudflare 大多数产品的软件都托管在我们统一的集中式源代码管理平台中。这意味着，只需检查代码库，我们就能找到整个平台中绝大多数密码学技术的使用情况。
虽然代码库集中化为我们带来了显著优势，但面对如此大规模的问题，我们仍需应对三项挑战。首先，我们的代码分散在许多代码仓库中。其次，密码学技术很少会在代码中明确表明自己的存在。相反，它往往隐藏在以下位置：
某个代码仓库导入的共享库中，尽管该仓库未必真正调用了这些库；
上游设置和协议默认值中，例如一个 TLS 1.3 监听器可能被配置为协商 X25519 之类的传统密钥交换算法，而不是后量子算法 X25519MLKEM768；
距离实际使用代码很远的算法配置文件中，例如某个 TLS 响应端所使用的密钥交换协议，可能固定在另一个代码仓库中的 YAML 文件里；
已经失效、仅用于测试或正准备弃用的代码路径中。
第三，发现密码学技术并不只是模式匹配的问题。使用 grep 搜索特定算法名称（例如“RSA”或“X25519”）会造成高估，因为它会找到未使用代码中的密码学内容；同时也会造成低估，因为它无法发现默认设置，以及依赖项和配置中的间接使用。更重要的是，它无法说明密码学技术究竟是如何使用的。一个传统的 ECDSA 签名可能用于 JWT、IPsec、TLS 或 SSH，而每一种场景的迁移路径都完全不同。许多使用场景还取决于连接的另一端：一台 TLS 服务器可能同时支持后量子密钥交换和传统密钥交换，而最终选择哪一种，则取决于客户端。
转向 AI
事实证明，AI 不仅擅长执行比 grep 更复杂的任务。模型可以搜索代码库、跨文件追踪证据，并返回结构化分析。它还可以从其他来源提取信息来丰富调查结果，例如我们的内部文档和工单系统。事实上，AI 甚至能够解释密码学技术的使用方式，以及应当如何进行更新。在开发 CryptoLabe 的过程中，我们一直在检验这一构想。
正如我们此前所说，我们的前两个目标是：（1）发现并理解代码库中密码学技术的使用情况；（2）获取衡量后量子密码学迁移状况的指标。为实现这些目标，当前版本的 CryptoLabe 分两个阶段执行扫描，如下图所示。
第一阶段是“发现”，首先会绘制代码仓库的结构图。随后，它会在源代码、配置文件、清单文件、锁定文件、脚本、测试和文档中搜索密码学技术。扫描所查找的内容包括密钥协商、签名、非对称加密、PKI、令牌、凭证、硬件安全模块集成等密码学技术的使用情况。这个发现阶段会生成一组“原始观察结果”。
每条原始观察结果都会进入第二阶段的一次运行。这个“分析”阶段首先会对照源代码重新检查观察结果。随后，它会调查该加密操作在运行时的使用方式、代码仓库所扮演的角色，以及它依赖哪些内部或外部相关方。必要时，它还可以检查其他代码仓库中的相关代码，以完成分析。最后，它会重新审视自己的结论，寻找缺失或相互冲突的证据，例如配置覆盖、仅用于测试的代码，或者对运行时行为作出的错误假设。
接下来，模型会为发现的问题分配一个分类。如果没有足够的证据进行分类，模型会将其标记为“需要更多证据”“外部依赖”或“未知”，而不是进行猜测。
以下是 CryptoLabe 当前使用的分类列表，其中包含一些兜底分类。随着迁移工作的推进，这些分类很可能会进一步细化。例如，我们可以将“加密”分类进一步拆分为“密钥协商”和“HPKE”等类别，大致思路就是如此。
经典加密
这是一个兜底类别，用于识别椭圆曲线 Diffie-Hellman 密钥交换（ECDHE，例如 X25519、P-256、P-384）、RSA 密钥协商，或其他公钥加密用途（例如 HPKE）。运行 Shor 算法的量子计算机能够破解这些技术，因此它们面临“现在收集、以后解密”攻击的风险。
经典签名
这是一个兜底类别，用于识别任何场景中使用的 RSA 签名或椭圆曲线签名（ECDSA），例如证书、TLS 握手或其他协议握手。Shor 算法能够破解这些签名。
经典令牌
我们发现了大量使用 RS256 或 ES256 的 JWT 令牌，因此专门为它们创建了一个分类。这些 JWT 使用经典的 RSA 和 ECDSA 签名；RFC 9964 定义了一种使用 ML-DSA 的后量子替代方案。
已为后量子迁移做好准备的混合密钥交换
用于识别 TLS 1.3 中的混合后量子密钥交换，即 X25519MLKEM768。这是我们代码库中最普遍的后量子加密使用方式。
已为后量子迁移做好准备
用于识别 TLS 1.3 中 X25519MLKEM768 以外的其他后量子密码学用途，例如 ML-DSA。
最后，它会生成一份面向两类受众的报告：第一类是需要了解迁移对其产品意味着什么的产品经理；第二类是需要获得足够详细信息以执行迁移的工程师。
下面是我们其中一份报告的局部截图：
尽管我们一直在以迭代方式对照源代码审查发现的问题，并与相关工程师共同核实，但目前还没有一个真实基准数据集，可用于以可复现的方式比较我们为 CryptoLabe 尝试过的不同提示词版本。
基于 Cloudflare Developer Platform 构建
我们在 Cloudflare Developer Platform 上构建了 CryptoLabe。其架构如下：
CryptoLabe 跨两个 Cloudflare Workers 运行。其中一个是负责执行扫描的扫描器 Worker；另一个是资产清单 Worker，负责提供仪表板、开放 API，并将所有内容存储在 D1 数据库中。两者通过 Service Bindings 进行通信。
当有人通过仪表板请求扫描时，扫描就会启动，inventory Worker 会将请求传递给扫描器。
编排扫描流程
我们需要一种方法，让扫描任务从开始到结束持续运行并保持在正确轨道上，同时不必自行构建任务编排系统。为此，我们采用了 Agents SDK。每个代码仓库都有自己的持久化协调器，该协调器基于 Durable Object（DO）构建。协调器前方设置了一个有界队列，用于限制同时运行的扫描数量。轮到某项扫描任务时，协调器会跟踪其进度，并负责处理取消、重试和恢复。
协调器本身不执行分析，而是将工作交给 Cloudflare Workflows，使其能够持久保存进度，并自动重试失败的步骤。协调器会让每个代码仓库依次经历四个阶段：
discovery Workflow（第一个扫描阶段，生成原始观察结果）
deep analysis Workflow（第二个阶段，针对每条原始观察结果运行）
merge Workflow（为指定代码仓库生成发现项列表，包括合并重复或相似的发现）
publish workflow（将结果交回 inventory Worker）
前两个工作流需要让模型访问代码仓库中的代码。我们希望这种访问彼此隔离，以免对代码库造成破坏。因此，CryptoLabe 会在每次扫描开始时，按照某个确切的 commit 下载一次代码仓库，然后将该快照存储到 R2 中。随后，每个 Workflow 都会将快照恢复到一个全新、短生命周期的 Cloudflare Sandbox 中；这是一个隔离容器。模型通过一小组只读工具在 Sandbox 中处理这份不可变的代码快照。这样，即使扫描仍在进行时代码库发生变化，也不会影响模型的工作。
大规模调用模型
如果要扫描我们所有的代码仓库——数量非常多——就必须同时考虑成本和容量问题。
在成本方面，模型循环通过 AI Gateway 将请求发送给托管在 Workers AI 上、经济实惠的开放权重模型。将模型置于 AI Gateway 之后，也可以在更好或更便宜的模型出现时轻松进行切换。
当我们同时扫描大量代码仓库时，容量便成了问题。模型请求的突发流量开始触发 AI Gateway 返回 HTTP 429（速率限制）响应，而各个扫描任务独立进行重试只会让突发流量更加严重。我们使用一个全局统一的 Durable Object 解决了这个问题，由它对所有扫描任务中的每一次模型请求进行节流，包括重试请求。当任何扫描任务触发速率限制时，所有任务会共享冷却状态并一同退避，让并发扫描任务共享可用容量，而不是彼此争抢。
前置条件与棘手情形
现在来谈谈我们的第三个目标：尽早发现前置条件和棘手情形。
关于生态系统的就绪程度，人们已经进行了大量讨论。
关于 PQ 迁移，我们现在还要透露更多信息。众所周知，PQ 迁移不可能在真空中进行。要想成功迁移，相关软件库（例如 BoringSSL）以及参与生态系统的各方（例如客户端、浏览器、源站、云代理、证书颁发机构等）都必须支持后量子密码学。标准也是衡量生态系统支持程度的重要指标，不过，一项标准仍处于“草案”状态，并不一定意味着无法着手部署。例如，我们早在 2022 年就在 TLS 1.3 中部署了 X25519MLKEM768，当时它在互联网工程任务组（IETF）仍处于“草案”阶段，直到 2026 年才最终定稿为 RFC 10024。
无论如何，我们想表达的是：要将一个系统升级为使用 PQ 密码学，就需要了解它的依赖关系以及生态系统对它的支持程度。
正因如此，CryptoLabe 引入了“先决条件”这一概念，用来标示那些无法由单个产品团队独立即时修复的发现项。
先决条件可能非常直接，比如“我们目前在迁移到后量子 JWT 方面遇到了阻碍”。我们之所以说这很直接，是因为后量子 JWT 已经有了相应标准（RFC 9964）。尽管如此，如果我们的软件库尚不支持验证后量子 JWT，或者我们使用的令牌颁发方尚不能签发后量子 JWT，我们就无法在全公司范围内要求每个产品团队开始对其 JWT 进行 PQ 改造。在解决核心先决条件之前，这项迁移无法推进。CryptoLabe 可以将那些（很可能）具有相同先决条件的发现项归为一组，这也有助于我们确定解决这些先决条件的优先级。
例如，下面的快照展示了 CryptoLabe 发现的六个以实现后量子 SAML 为先决条件的问题。（SAML 是一种用于单点登录（SSO）的协议。）
另一方面，有些密码学应用甚至缺乏最基本的生态系统支持。我们一直将这些情况称为“棘手案例”。为了找出它们，我们另外编写了一条提示词，忽略密码学的“常规”用法（例如内部系统之间的普通 TLS），转而寻找自定义密码协议、用于容量受限字段的密钥或签名、内置于硬件中的密码技术、专门的密码学构造（例如盲签名）、尚无 PQ 标准的协议，以及对尚不支持 PQ 密码学的外部方的依赖。
这条提示词比 CryptoLabe 使用的提示词更短、更简单，因为它唯一的任务就是找出棘手案例。在定性评审中，我们发现，让它一次性扫描我们的所有代码仓库，同时接收来自内部工单和文档系统的上下文信息，能够取得更好的结果。
下面是我们发现的一个“棘手案例”：HTTP 标头中携带了一个证书。后量子证书和签名比传统证书和签名更大，因此，如果该标头（或某个中间组件，或处理该标头的应用程序）假定证书具有特定大小，那么更改签名算法可能会导致系统发生故障。下一步，我们需要确定这段代码是否会长期继续使用。如果会，我们就需要测量相关的大小限制，并决定如何容纳更大的证书。
这里的一项重要经验是，任何一种扫描都无法发现所有问题。我们逐个代码仓库进行的扫描，在发现常见的密码学使用方式方面卓有成效。与此同时，这种针对性扫描更适合发现“棘手案例”，因为它忽略了那些已经得到充分理解的密码学用法，并且掌握了有关每款产品及其依赖项的更多上下文信息。
归根结底，不同的方法会发现不同的问题，而每一项发现仍然需要由真正了解系统实际运行方式的工程师进行核查。
分享我们的提示词
过去几个月里，我们一直在摸索为 CryptoLabe 编写提示词的最佳方式。目前，我们还没有一个用于比较不同提示词表现的真实基准数据集，也不确信自己已经覆盖了代码库中所有密码学用法。相反，我们通过运行扫描、与负责维护这些代码仓库的工程师共同审查发现、调查审查过程中暴露出来的遗漏，并修改提示词来持续迭代。尽管如此，我们还是决定公布部分精选提示词，以便其他团队学习并调整我们的方法。这些提示词只是起点，并非可独立运行的 CryptoLabe 版本；其结果质量将取决于可用的模型、工具、上下文信息和工程审查。
思考你自己的后量子迁移
在 Cloudflare，我们正以一种最大化覆盖的方式推进后量子（PQ）迁移，因为我们的目标是成为面向客户乃至整个互联网的后量子密码学服务提供商。但大多数组织并不需要一开始就查找其每一款产品、每一个代码仓库中的所有密码学用法。事实上，大多数组织都不应该这样做，因为在现阶段，这会浪费宝贵的资源。
在扫描任何一个代码仓库之前，你可以尽可能先批量保护网络流量。如果你的网站通过 Cloudflare 运行，我们现在已经使用后量子加密来保护你的传输中数据；你可以通过我们全新的 PQ 可见性功能进行查看。我们的 SASE 平台 Cloudflare One 可为专用网络流量提供后量子加密。后量子加密无需额外付费，也不要求你升级企业网络中的每一台源站服务器或每一个私有应用程序。在你逐步发现并理解自身系统内部的密码学使用情况期间，这可以为你提供一项补偿性控制措施。
详尽的密码学清单并不是采取行动的先决条件。相反，组织应首先确定哪些系统一旦遭到入侵会造成最严重的影响，查明这些系统对密码学技术的使用情况，然后按照优先级顺序将相关密码技术升级为后量子（PQ）方案。以下是一种入手方式：
为一个重要系统选择代码仓库。
首先选择一个处理敏感数据或需要长期保存的数据、负责验证用户或软件身份，或者暴露于公共互联网的系统。
对该代码仓库运行密码学发现扫描。
我们希望对 CryptoLabe 的介绍能为这项工作提供帮助！
验证结果。
请负责该系统的团队验证密码学发现扫描的结果，并确认扫描发现的密码技术是否需要长期使用，以及是否需要升级为后量子方案。需要注意的是，如果已经部署了其他补偿性控制措施，相关密码技术可能并不需要立即升级为后量子方案。
确定行动的优先级。
弄清楚哪些升级现在就能实施，哪些升级仍受到阻碍。记录需要密码库、供应商、标准组织或组织内其他部门协助解决的共用前置条件。为扫描发现的问题确定优先级，并制定计划，优先处理影响最大的系统和前置条件。
这样一来，即使没有完整梳理组织内的每一项密码学操作，你也能初步形成一份后量子迁移计划。CryptoLabe 仍在不断发展，但在我们规划迁移工作时，它的扫描及其结果为我们提供了许多启示。我们希望，在你继续推进自己的后量子迁移工作时，这些共享经验能有所帮助。
致谢：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 团队。
来源与参考
收录于 2026-09-30