AI 遇见密码学 2：AI 在 OpenVM 的 ZkVM 中发现了什么

这是该系列的第二篇文章。如果您还没有阅读 Cloudflare 的 CIRCL 上的第一篇，它提供了更多有关我们为何运行这些实验以及如何设置管道的背景信息。在这篇文章中，我们将我们的人工智能审计员 zkao 指出了 OpenVM 的 zkVM ，它在其来宾库 openvm-pairing 中发现了一个严重的健全性错误，该错误允许恶意证明者伪造任何配对相等性。请注意，这并不是 zkVM 证明系统本身的健全性错误。它只影响使用易受攻击的库的代码。这篇文章中的错误被指定为 CVE-2026-46669 并在 OpenVM 1.6.0 中修复。据我们所知，所有基于 OpenVM 的合作伙伴都已升级到该版本。注意澄清，与第一篇文章相同：人工智能产生了候选结果，而不是最终报告。然后，我们团队中的人员验证了该问题，确认了可利用性，了解了全部影响和受影响的项目，并处理了披露问题。在这种情况下，由于 zkao 自己制作了详细的报告和最小的 PoC，非常快速的手动分类足以决定值得与 OpenVM 团队分享。它是如何发生的 四个月前，我们扫描了 OpenVM，作为我们人工智能实验的一部分，就像我们一开始扫描所有东西一样：一个带有简单提示的法学硕士，然后是一个具有我们专家维护技能的法学硕士。我们使用 Opus 4.6 和 Codex 5.3 运行它。 Opus 4.7 和 Codex 5.4 一出来，我们就再次运行它们。候选发现都是有效的观察结果，模型自信地将其中一些标记为“严重”或“高”，但实际上没有一个是可利用的。我们的假设是，zkVM 对于简单的 LLM 设置来说太复杂了，无法处理 300K 令牌甚至 1M 上下文令牌。模块之间的依赖关系比典型库中的依赖关系要密集得多。通常可以通过简单地为每个子代理提供一个映射到单个加密原语的文件夹来并行审核加密库。每个子代理读取少量行，仅应用相关技能，将其发现写入 markdown 文件，然后主代理将这些文件缝合在一起。所有这些都是通过流行的代理编码工具（例如 Claude Code 和 Codex）开箱即用，几乎不需要人工指导。这种方法不会转移到更复杂的代码库，例如 OpenVM。在那里，除了容易实现的目标之外，子代理的有用输出并不是错误列表。您可以拥有一个可证明安全的模块 A 和一个可证明安全的模块 B，其组合仍然不安全。因此，在“孤立”模式下寻找错误无法捕获有意义的错误。相反，子代理的输出应该是有关模块的知识：它假设什么，它委托给调用者什么，以及它默默地依赖什么不变量。然而，很好地表示这种输出是困难的部分。太短了，它会跳过错误实际所在的实现细节。太长了，它会在与其他任何内容组合之前溢出主代理的上下文。据我们所知，至少在撰写本文时，上述代理编码工具并没有有效解决这个问题。考虑到这一假设，我们决定在 OpenVM 上运行 zkao，尽管我们这些实验的最初规则是仅在普通法学硕士已经发现真正的 bug 后才运行 zkao。我们在 zkao 的上下文工程上花费了大量时间，并且将我们自己专家的工作方法编码为可重用的流程来查找漏洞，因此它似乎是适合这种情况的正确工具。经过九个半小时的扫描，返回了许多结果。与之前的实验类似，我们没有时间深入研究每一个发现。快速浏览后，有一个问题立即脱颖而出：其中一个来宾库中的配对检查存在严重的健全性错误。我们的假设成立，几个月的努力得到了回报！虽然只有一个错误要分享，但为了与第一篇文章保持一致，这里是错误一目了然。严重性和修复一览 # Bug AI 严重性 OpenVM 严重性 修复提交 发现 1 个 openvm-pairing 配对检查缺少对比例因子的正确子字段检查 严重 严重 a720e2c zkao 这次，AI 严重性和维护者严重性一致。 Bug 1：openvm-pairing 配对检查缺少对比例因子的正确子字段检查 背景配对是 Groth16、带有 KZG 的 PLONK 和 BLS 签名下的引擎。在所有这些协议中，验证者通常不要求一个配对值。它询问配对的乘积是否为一： $$ \prod_i e(P_i, Q_i) = 1。 $$ 从这个是或否的答案中，验证者得出结论：SNARK 证明是有效的，KZG 开局是正确的，或者签名已验证。因此，如果证明者可以使错误的配对产品看起来是一个，那么建立在其之上的所有东西都不再健全。配对是双线性映射 $$ e : G_1 \times G_2 \to G_T, $$ 其中 $G_1, G_2, G_T$ 是阿贝尔群。在我们的例子中，$G_1$ 和 $G_2$ 是