摘要

  • RFC 10032 不只定义 AEGIS-128L、AEGIS-256 及其向量化变体，还把同一族内部机制用于三种不同角色。加密要求每个 (key, nonce) 只用一次，并且验证失败前不得释放明文；流模式按定义丢弃认证标签；只有 MAC 函数允许同一对参数处理不同输入。
  • IANA 代码点、测试向量或性能数字，只能证明命名协调、特定变换或测试条件。它们不能证明应用选对了角色、隔离了密钥用途、维护了正确的 nonce 空间，也不能证明未经认证的字节没有越过输出边界。

设想一个代码审查页面：同一把十六进制密钥，同一个 nonce，旁边有三个几乎并列的入口。第一个入口返回密文和标签；第二个入口返回密钥流；第三个入口返回 MAC。内部都使用 AEGIS，参数形状也相似，于是开发者把它们包装成一个 aegis() 帮助函数。

这个抽象减少了代码，却抹掉了权限。第一个入口的参数对不能再次加密。第二个入口根本没有保留认证标签。第三个入口才拥有复用例外，而且它的标签既不是哈希，也不是派生密钥。共享内部轮函数不等于共享外部承诺。

RFC 10032 于 2026 年 9 月作为 IRTF 流的 Informational RFC 发布，记录 CFRG 共识，并不是 IETF 标准轨规范。它规定 AEGIS-128L、AEGIS-256、AEGIS-128X 和 AEGIS-256X。X 模式面向具备大向量寄存器和向量 AES 指令的 CPU；是否使用它们属于协议配置与实现选择，不能由“支持 AEGIS”自动推出。

IANA 为基础模式及 X2、X4 形式分配了 32 至 37 六个 AEAD 标识符。代码点解决共同命名，不携带角色、标签长度、关联数据结构、密钥用途、nonce 分配方法或失败输出规则。BTW 既有 RFC 10032 文章已经拥有“代码点不等于双方协商与现场使用回执”的论点。本文从下一道边界开始：套件已经选定之后，应用究竟调用了哪一种工作角色？

AEAD 的核心是一道释放闸门

认证加密接收消息、关联数据、密钥和 nonce，输出密文与 128 或 256 位标签。解密必须计算预期标签，以恒定时间比较，并在成功后才返回明文。

用于加密的 (key, nonce) 必须唯一。换一种标签长度并不会产生新的 nonce 域。若同一对参数加密两个消息，会立即暴露消息之间的逐位差异，并在规范描述的失效条件下暴露内部状态。nonce 可以公开、可以预测；不可接受的是同一密钥下重复。

规范给出随机 nonce 的数量边界。AEGIS-128L 与 AEGIS-128X 在一把密钥下最多随机加密 2^48 个消息时，碰撞概率约为 2^-33。AEGIS-256 与 AEGIS-256X 在分析中没有实际数量限制。但“没有实际限制”只描述正确随机生成时的碰撞风险，绝不允许刻意重用。

另一条义务发生在输出端。标签验证失败时，未验证明文、错误标签或计算所得标签不得交给调用者；临时明文缓冲区必须在返回前清零。若解析器、日志、数据库写入或回调在最终验证前已经看见部分明文，即使公开 API 最后返回错误，释放闸门也已经失守。

因此，一次 AEAD 调用的证据不应只有“成功”。它应连接角色、变体、标签长度、密钥标识、nonce 分配事件、关联数据的规范编码、验证结果，以及任何提前发生的副作用。密码标签裁决的是一组比特；它不会阻止应用架构先行动。

流模式有意放弃认证证据

RFC 10032 的流函数用 AEGIS 加密全零消息，不使用关联数据，并丢弃认证标签。实现甚至可以省略 Finalize。返回值就是密钥流。

这种服务本身并无问题。它只是没有 AEAD 的承诺：输出不是经过认证的消息，不证明某个对端生成或接受了数据，也不附带可核验的标签。若调用方把密钥流同明文组合，外层构造必须另行提供完整性、认证和正确的“先验证后释放”顺序。

风险来自语义继承。监控系统把 aegis_stream() 和 aegis_encrypt() 都显示为“AEGIS 加密”；迁移工具保留算法字段，却换掉函数入口；下游团队以为标签存放在别处。实际上标签按定义被丢弃，根本没有可寻找的对象。

流角色应使用独立密钥用途、独立 nonce 空间，并在类型系统中明确标为“未认证密钥流”，而不是交付一个需要靠口耳相传才能解释的字节数组。若存在外层认证构造，回执必须指出其名称、执行顺序和失败边界。

MAC 拥有唯一的复用例外

MAC 函数吸收数据并返回 128 或 256 位标签。RFC 10032 明确说，这是唯一允许同一 (key, nonce) 对处理不同输入的函数。

这句话的主语是 MAC 函数，不是整个 AEGIS 家族。若平台建立一条“AEGIS nonce 策略”，MAC 的例外就可能泄漏到加密入口。底层算法不会报告角色越权；它仍会算出字节。

MAC 标签还有负面边界。密钥已知时，攻击者可以构造内部状态碰撞，因此它不得充当哈希。标签也不保证均匀随机，因此不得作为密钥派生材料。长度看起来像摘要或新密钥，并不会赋予相应性质。

有效的控制应落在架构上：按角色签发密钥标识；使用不同派生标签；分开 nonce 分配器；让 AEAD、STREAM、MAC 接口拒绝其他角色的密钥；记录标签允许承担的用途。依赖开发者记住一段例外说明，不是控制面。

标签长度与关联数据仍由协议负责

RFC 10032 允许 128 和 256 位标签。在所述 receiver-binding 场景中，短标签约有 64 位 key-commitment 强度，长标签约有 128 位。IANA 代码点不记录这一选择。

commitment 还取决于谁能控制关联数据。攻击者不能控制关联数据的受限情形下，AEGIS 是 fully committing；攻击者能够改变关联数据时，引用的分析说明可以有效找到多个能验证同一认证密文的密钥。若协议需要更强性质，可以先用满足碰撞与原像抗性的函数哈希关联数据，或把无歧义编码通过 KDF 的 info 输入绑定，同时遵守 RFC 对 salt 与编码方式的限制。

这些都是协议层构造，不会随代码点自动出现。必须列明哪些字段进入关联数据、如何序列化、谁能控制它们，以及应用真正需要哪种 commitment。原语认证收到的比特，不认证组织对字段的解释。

测试向量到不了托管边界

RFC 10032 提供大量测试向量，可以证明某个实现对固定输入给出预期输出。跨实现测试还能证明双方对这些案例一致。它们不能证明生产调用了正确角色，更不能证明失败路径没有外泄。

部署验证应主动制造角色混淆：让一种角色的密钥进入另两种接口并确认拒绝；即使改变标签长度也重复加密 nonce；确认 MAC 复用测试不影响 AEAD 分配器；检查流输出始终标为未认证；破坏密文、标签和关联数据并观察没有明文、回调或副作用；把 MAC 标签交给哈希与 KDF 接口并确认拒绝；核实加载的二进制与 CPU 路径；按角色记录现场计数器。

计时、功耗与故障注入安全性还取决于实际 AESRound 实现和威胁模型。规范指出初始化后可以清除临时密钥，因为后续操作只使用派生状态。特定编译器与库是否真的清除，仍然只能由运行代码证据回答。

最小角色回执应保留：应用目的与威胁模型；角色；变体与并行度；标签长度；密钥身份、用途和生命周期；nonce 命名空间与分配事件；关联数据结构；库版本与运行路径；验证与清零结果；输出闸门；现场计数器；应用接受或回滚决定。

Lu Heng 的最小初始规范原则支持一个小而共同的密码原语，同时把后续决定留给真正承担结果的主体。注册表负责命名，库负责执行，协议负责结构，应用负责授权动作。现实层纪律则阻止 RFC、测试向量或有效标签越级借走下一层的权力。

RFC 10032 最重要的运营启示，不只是 AEGIS 能做三件事，而是同一套机械结构不会自动合并三套责任。名字可以相同，回执必须分开。

来源