Aegon：可自审计密钥透明系统如何破解审计难题

端到端加密消息中，服务器负责分发公钥——但如果服务器作恶，悄悄替换成攻击者的公钥，加密依然“完美”，私密消息却送错了人。密钥透明（Key Transparency）正是为解决这一问题而生。剑桥大学研究者 Hossein Hafezi 在 Cryptography Talk Series 中介绍了其团队的新工作 Aegon，一个可自审计的密钥透明系统。它是此前 IronDict 的续作，目标直指现有部署方案（Signal、WhatsApp、iMessage）中最昂贵的环节：审计。

密钥透明的核心矛盾：谁来做审计？

密钥透明的基本模型并不复杂：服务器将时间划分为 epoch，每个 epoch 在公共公告板上发布目录承诺及状态转换证明。客户端做两件事——查询他人公钥（lookup），以及证明自己的公钥从 epoch i 到 epoch j 未被篡改（一致性证明）。

问题出在一致性证明的构建方式上。早期方案 Coniks 要求客户端逐个检查每个 epoch，离线越久计算量越大，对普通用户不现实。Seamless 系列方案引入版本号与审计员角色：版本号仅在公钥变更时递增，审计员每 epoch 验证服务器是否遵守规则。客户端回归时只需比对首尾版本号，负担大幅降低。这套思路已被 Signal、WhatsApp 和 iMessage 采用。

但审计员的负担并不轻。据演讲中给出的数据，WhatsApp 密钥透明的审计员每分钟需下载并哈希约 80MB 数据。这导致实际部署不得不依赖外部审计服务——WhatsApp 使用 Cloudflare，Signal 使用 Cloudflare 与 Trail of Bits。Hafezi 还指出一个角色混淆问题：公告板（保证一致性视图）与审计（计算验证）本是逻辑上不同的角色，却被同一组织兼任。公告板只需交换少量认证 Merkle 根，本可由大量节点参与；审计则可独立并行。

Merkle 树是密钥透明方案中最常用的承诺结构。服务器将所有用户名-公钥对按某种顺序排列为叶子节点，逐层哈希得到根哈希并公开。任何客户端只需持有根哈希和一条从叶子到根的路径（约 log n 个哈希值），就能验证某个公钥确实在目录中。其优点是证明大小随条目数对数增长、验证极快；缺点是每次更新都会改变根，审计员要确认“新根是旧根加上合法更新”需要额外证明，且这些证明会随更新量累积膨胀——这正是 WhatsApp 每 epoch 需下载数十 MB 审计数据的根源。

IronDict 的思路：用多项式承诺替代 Merkle 树

现有部署几乎全部基于 Merkle 树，扩展性好但审计证明随更新量膨胀。代数路线（如 VerSA）虽能压缩证明，服务器成本却难以支撑百万级以上条目。IronDict 选择了一条中间路线：用多项式承诺构建透明字典。

具体而言，多线性多项式在布尔超立方上的取值唯一确定该多项式，因此一张表可以被表示为一个多项式，用多项式承诺方案（PCS）承诺后，在布尔点打开即可证明某位置的值。真实场景中标签和值都是任意字符串：值通过抗碰撞哈希映射到域元素（保留 0 表示空位）；标签则通过开放寻址（open addressing）分配位置——哈希标签与计数器生成候选序列，遇占用则探查下一个，需约 4 倍过供应以保证效率。

IronDict 维护两张映射：索引映射记录标签到内部位置的稳定分配，值映射记录当前位置的值。一致性证明则依赖“随机化一致性机制”：对相邻 epoch 的差值向量乘以随机挑战后累加，服务器必须先承诺更新再获知挑战，因此变更与其逆转无法自动抵消——这恰好防御了“幽灵密钥”攻击（临时替换后恢复原样）。客户端只需比对端点处随机化向量的认证打开值。

多项式承诺方案（PCS） 允许承诺者对一个多项式 f 生成简短承诺 C，之后可对任意点 x 打开 f(x) 并给出证明，验证者用 C 和证明即可确认该值正确，而无需知道 f 的完整系数。安全性依赖密码学假设：敌手无法找到两个不同的多项式在同一承诺下打开出不同值。常见实例包括 KZG（基于配对，承诺和证明都是常数大小，但需可信设置）、Bulletproofs（透明设置但证明较大）等。在透明字典中，PCS 的价值在于把整张表编码为一个多项式，并对单个位置的查询给出常数大小证明，避免 Merkle 路径随更新累积。

幽灵密钥攻击指恶意服务器临时将某用户的公钥替换为攻击者公钥，诱使他人加密消息，随后在下一个 epoch 前恢复原公钥，使一致性检查“看起来从未变过”。随机化一致性机制之所以能防御此类攻击，关键在于服务器必须先承诺更新、后获得随机挑战，因此它无法预知挑战值来构造相互抵消的变更与逆转；任何临时替换都会在随机加权后的差值向量中留下痕迹，被客户端在端点比对时发现。

Aegon 的三项改造：从可用到可部署

IronDict 的审计确实高效，但服务器侧存在四个瓶颈：每 epoch 保留完整快照（十亿级字典约 500GB/epoch，而 epoch 仅 30 秒）；不支持横向扩展（十亿键需约 2TB RAM 加 256GB SRS）；全局 sumcheck 使证明生成与字典规模线性相关，epoch 延迟约 15 分钟；以及上述存储与 setup 问题。

Aegon 针对性地做了三件事：

其一，用标签级一致性检查取代全局索引检查。 开放寻址中，一个标签的解析路径包含若干“前缀位置”和最终“分配位置”。Aegon 对索引映射也应用随机化机制，客户端验证解析路径上所有位置在整个区间内不变——前缀位置保持原值，分配位置持续返回该标签。服务器计算量因此只与更新数线性相关，不再随字典规模增长。

其二，字典分片。 协调者用可验证随机函数（VRF）将标签确定性地路由到独立运行的 Agon 实例。查询只需涉及目标分片，协调者无法伪造 VRF 证明来重定向。Hafezi 提到，这套分片架构同样适用于 WhatsApp 的 AKD 方案。

其三，紧凑历史证明代替全量快照。 每个 epoch 只存储与该次更新相关的少量打开值，存储量与更新数成正比而非字典大小。

可验证随机函数（VRF） 是一种带证明的伪随机函数：持有私钥的协调者对输入 x 计算输出 y = VRF_sk(x) 及证明 π，任何人用公钥即可验证 y 确由 x 经该函数生成，且无法预测或操纵 y。在分片架构中，协调者用 VRF 将标签映射到分片编号，客户端可独立验证路由正确性，从而防止恶意协调者把某标签的查询重定向到受控分片、返回伪造公钥。VRF 的确定性还保证同一标签始终落入同一分片，维持查询一致性。

性能对比：审计证明从 80MB 降到 45KB

Aegon 已实现优化代码库，并在与 WhatsApp 密钥透明相同的设置下对比（30 秒 epoch、每秒 1250 次更新）。结果显示，Aegon 的查询证明大小、验证开销与服务器查询延迟均更优，部分归功于分片架构。更关键的是审计证明：Aegon 的 45KB 证明覆盖整个密钥透明历史，可在一秒内验证，客户端可按周或按月检查，无需每 epoch 在线。相比之下，WhatsApp 的审计证明是每 epoch 约 80MB。

Aegon 的构造对多项式承诺方案是通用的，具体实例化采用 KZG，效率高但需要 powers of tau 可信设置，且为前量子安全。团队正在推进后量子版本，并行探索两个方向：替换为后量子承诺方案，以及支持标识符复用——当前索引字典会因用户名频繁更换而饱和，他们计划引入回收机制，并形式化 Optics 提出的“生命周期”概念，用“认证年龄”让用户判断所联系标签的新旧程度。Hafezi 还透露正在向 IETF 提交相关标准化讨论。

隐私与部署现状

在问答环节，Hafezi 表示 Aegon 的隐私优于 Seamless 系方案，其隐私在零知识意义上定义，不泄露额外信息。但他也坦言，若无访问控制，元数据隐私在实践中意义有限——知道手机号即可查询公钥。关于部署，他仅透露 WhatsApp 团队内部“在试用 Aegon”，是否上线未知。

从 IronDict 到 Aegon，这条代数路线的价值在于重新划分了信任与计算的边界：审计不再是需要专门基础设施的昂贵操作，而是每个客户端都能独立完成的自审计。对于每天承载数十亿密钥查询的通讯平台而言，这可能是密钥透明从“可部署”走向“可持续”的关键一步。