摘要

  • RFC 10032 是 IRTF 信息类文档，反映 CFRG 共识，并非 IETF 标准轨强制要求；六个 IANA 标识符提供稳定命名，而不是部署义务。
  • 登记表区分 AEGIS-128L、AEGIS-256 与四种 X2/X4 并行形式，却不编码 128 位或 256 位认证标签。并行模式是可选项，只有各方明确同意同一变体时才应选择。
  • 库的自检可以证明某个原语实现对固定向量给出正确结果，不能证明双方协商、实际加载的二进制与硬件路径、nonce 和关联数据构造，或真实流量使用的套件。
  • 一份算法托管回执应连接文档与登记快照、协议配置、经认证的选择、代码点与标签、密钥和 nonce 生命周期、关联数据编码、运行路径、正反测试、失败行为、计数器、降级与回滚。

六个编号解决的是命名冲突

IANA 为 AEAD_AEGIS128L 分配 32，为 AEAD_AEGIS256 分配 33；34、35 对应 AEGIS-128 的 X2 与 X4，36、37 对应 AEGIS-256 的 X2 与 X4。登记的价值很明确：公开协议可以引用同一个名字和数字，而不会把相互不兼容的算法放在同一标识符下。

但登记项不是一次连接的证词。创建 AEAD 通用接口和登记表的 RFC 5116 明确指出，IANA 登记不代表认可算法或其安全性。该接口也不替调用方决定防重放与访问控制。这些属于具体协议和部署。

RFC 10032 定义算法、参数、操作注意事项与测试向量，却没有为 TLS、IPsec、QUIC、存储系统或专用信道制定一种通用协商。每个采用它的协议仍须决定：是否提供 AEGIS，用哪个标识符表示哪个配置，如何固定标签长度，怎样产生密钥和 nonce，哪些字节进入关联数据，以及认证失败后怎样处理。

因此，“软件包含 AEGIS”只是一项能力事实；“本次会话由 AEGIS-128X2 以某组参数保护”则是选择与运行事实。一个数字无法把两者自动连接起来。

同为 RFC，不等于同一种授权状态

RFC 10032 于 2026 年 9 月在 IRTF 流发布，类别为 Informational。它代表 CFRG 的研究组共识；状态说明同时写明，这不是 IETF 产品或标准，IRTF 成果也可能不适合部署。

这不是对技术内容的贬低，而是对审议路径的准确标注。RFC 5743 描述研究组准备、IRSG 审查和 IESG 冲突检查；RFC 7841 说明非 IETF 流文档通常没有经过 IETF 标准所需的全组织审查与批准。

至少有四个事实不能合并：CFRG 形成研究共识，IRSG 批准发布，IESG 检查与标准化工作的冲突，IANA 分配唯一标识符。它们都不等于某个协议已经采用、某个产品默认启用，或一对端点在会话中完成选择。

2026 年 9 月 20 日的 IANA 公共页面还提供了一个时间切片：六条记录已经出现，引用栏仍显示第 18 版草案，页面标注最近更新于 7 月 7 日。这不是代码点无效的证据，而是提醒审查者分别保存当时看到的发布状态和登记状态。

代码点没有带上标签长度

AEGIS-128L 使用 128 位密钥与 nonce；AEGIS-256 使用 256 位密钥与 nonce。两者均允许 128 位或 256 位认证标签。六个登记名称编码了算法族，并在并行形式中编码 X2 或 X4，却没有编码标签长度。

这个缺口会改变安全陈述与线路格式。RFC 10032 在其特定承诺性质分析中，把 128 位标签对应的工作量描述为约 2^64，把 256 位标签描述为约 2^128。两个端点即使都选择代码点 32，也可能一个等待读取 16 字节标签，另一个等待 32 字节。登记匹配是真的，互操作仍然失败。

密文与标签的边界也必须确定。规范允许二者分开传递，或把标签紧接在密文之后。一份只记录“AEGIS-128L”的回执无法告诉复核者实际解析了多少位，边界由什么配置决定。

关联数据同样不是抽象的缓冲区。RFC 5116 举例说明地址、端口、序列号与协议版本等明文字段可以被认证。RFC 10032 的完整承诺性质带有攻击者不能控制关联数据的限制，并为需要更强性质的协议描述了额外构造。字段集合、顺序、长度、版本绑定与域分离都必须进入协议证据。

并行性能也是兼容性选择

AEGIS-128X 与 AEGIS-256X 面向宽向量寄存器和向量 AES 指令，X2、X4 分别代表并行度二和四。不同处理器、编译选项与实现可能得到不同收益。

RFC 10032 对采用方式设了清楚的边界：只有所有参与方都同意某个具体并行变体时，协议才应选择它；AEGIS-128L 与 AEGIS-256 应保持默认，且实现可以完全不支持并行形式。

这意味着一张漂亮的 X4 吞吐图并不能创造可移植套件。远端可能只支持基础形式；部署二进制可能没有编译 X 路径；虚拟机迁移后可见指令集可能变化；运行时分派器也可能退回另一条路径，而配置界面仍显示“AEGIS”。

可核验的证据必须拆成三层：协议提供并选择了什么；每个端点实际具备什么能力；进程在该次运行中执行了哪条实现路径。三者有关联，却不可互相替代。

nonce 的位数不能代替托管

在加密用途中，RFC 10032 要求同一密钥下的 nonce 不得重复，即使前后使用不同标签长度也不例外。重复会立即暴露两条消息的按位异或差。nonce 可以公开、可预测，也可以来自计数器或长周期生成器。

若随机产生 nonce，128 位家族在文档给出的约 2^-33 碰撞概率下，每个密钥最多可处理 2^48 条消息；256 位家族被描述为没有实际的随机 nonce 数量限制。但“没有实际限制”不等于“不需要托管”。唯一性规则仍在，系统仍须说明怎样生成和记账。

部署需要界定唯一性域、密钥纪元、重启持久化、随机源、分片范围与快照回滚检测。两个从同一快照恢复的进程，可能同时相信自己拥有下一个值；扩大字段不会自动选出真正的所有者。

密钥也需要相同粒度的记录：生成或派生方式、绑定的协议上下文、纪元起止、用户隔离、标识符和清除边界。RFC 10032 允许初始化后清除临时密钥，因为后续操作依赖内部状态。实际实现是否做到，仍需运行证据，而不能从规范文字直接推定。

自检到不了真实会话

RFC 10032 给出了 AES 轮、两种基础算法、X2/X4 变体和 MAC 形式的大量固定向量。它们很适合发现字节序、收尾、非整块输入和标签生成错误。独立实现之间的交叉测试还可以排除同源缺陷。

负向测试承担另一类证明。修改标签、关联数据字段、nonce 或并行度都应失败。规范要求失败时不得输出未验证明文和计算得到的标签，必须覆写解密缓冲区，并以常数时间比较标签。一条加速路径即便通过所有正向向量，如果在认证前泄露明文，就没有保持规定行为。

再完善的实验室测试也不能证明真实握手提供过该套件，双方认证过选择，加载的是预期共享库，硬件路径确实启用，或使用量始终处于计划的密钥纪元内。这些是运行事实，必须由运行记录承担。

一份十四部分的算法托管回执

以下回执是 Daniel Kade 提出的编辑性运营控制，不是 RFC 10032 的字段，也不是 IETF、IRTF、CFRG 或 IANA 的合规证书。

第一，保存文档身份、文档流、类别、发布与勘误快照，以及 IANA 登记快照。第二，写明调用协议、版本、套件配置和配置代次。第三，保留经过认证的提供—选择记录，或等效的双方同意证据。

第四，记录数字代码点与精确的基础、X2 或 X4 变体。第五，绑定标签长度及密文—标签帧格式。第六，保存双方能力与不支持时的行为。第七，记录密钥来源、派生上下文、纪元、标识符与清除边界。

第八，说明 nonce 构造、持久化、唯一性域、重启处理和逐密钥使用计数器。第九，列出关联数据字段与规范化序列化。第十，标识库版本、CPU/向量路径与回退路径。第十一，保存正向向量、跨实现结果与负向测试。

第十二，记录认证失败语义、明文抑制、常数时间证据与告警。第十三，把所选套件连接到范围明确的会话或数据包以及用量遥测。第十四，保留后备规则、反降级、回滚触发器、兼容集退出条件和证据保存期限。

登记快照不能证明握手；握手不能证明重启后的 nonce 持久化；测试向量不能识别加载的二进制；缺少密钥纪元与关联数据规则的数据包也无法解释为何应被接受。回执的价值，正是拒绝用一个“支持”状态掩盖这些不同陈述。

来源