摘要

  • RFC 9771 把常见的 AEAD 形容词分成四类声明；混淆这些类别，会让一个对算法成立的真命题在部署边界上产生误导。
  • 可辩护的采购或放行决定需要一份“性质凭据”，把精确声明连接到安全模型、构造与版本、API 行为、负面测试、密钥生命周期和协议集成。

形容词从来不等于保证

“认证加密”听起来像一项已经完成的安全决策，实际并非如此。它是一种密码原语，保护能力取决于算法、密钥与 nonce 纪律、关联数据、调用接口以及外围协议状态共同组成的契约。IRTF 的密码论坛研究组在 2025 年 5 月发布 RFC 9771，其价值正在于拒绝把这份契约压缩成一个笼统的质量标签。

这是一份 Informational RFC，并非互联网标准，也不为任何算法颁发部署证书。它提供的是分类学：先把常规安全与“面对更强攻击者时仍成立”的附加安全性质分开，再把二者同实现特征、需要新接口的附加功能分开。于是，买方、评审者和运营方能先判断供应商说的是哪一种句子，再判断这句话需要哪一种证据。

沿用 RFC 5116 的常规 AEAD 接口接收密钥、nonce、关联数据和明文，输出密文；解密则输出明文或失败。这个紧凑接口已经藏着一项运营义务：同一密钥下每次调用的 nonce 必须唯一。产品资料写着“AES-GCM”，并不会告诉买方由谁保证唯一性、快照恢复后是否仍然唯一、并发发送方如何划分空间，也不会说明硬件加速器与软件回退是否共享状态。

RFC 9771 扩充了词汇，却没有替系统回答这些问题。它不是“形容词越多越安全”的菜单，而是一张互不相同的证明义务地图。

四类声明，四套证据

声明类别 改变了什么 应当随附的证据
常规安全 基线机密性与密文完整性目标 精确构造、参数、安全模型、具体界限、测试向量和使用上限
附加安全性质 攻击者获得 nonce 重复、多用户、泄漏或提前获得明文等能力 分别陈述机密性与完整性、形式化模型、不等价说明及面向误用的负面测试
实现特征 计算以何种方式执行 实际实现路径、内存与遍历行为、缓冲和验证边界、硬件与回退路径一致性
附加功能 调用方获得更新操作或可选密文扩展等新接口 新 API 契约、重新定义的常规安全目标、状态转换、兼容规则和失败语义

这一区分揭示了一种常见的保证错误。“单遍”“可并行”和“可流式处理”描述计算方式，本身不证明机密性或完整性。RFC 9771 还特别指出，流式构造在某些应用中可能需要分块安全和“释放未验证明文”（RUP）完整性。因此，吞吐率基准不能充当流式 API 的安全凭据。

反过来也一样：针对密码构造的形式化结果，不能证明包装器保留了该结果。若解密器在标签验证前把字节交给应用，系统就进入 RUP 场景。明文既已主动释放，常规机密性不可能继续成立；适用的是不同的完整性与明文认知目标。于是，同一原语的缓冲式 API 与增量式 API 可能承载完全不同的安全声明。

附加功能把边界画得更清楚。RFC 9771 将增量认证加密和 robust authenticated encryption 放在附录，因为二者都超出了常规 AEAD 接口。在后者中，调用方选择密文扩展量，以长度换取该扩展量下尽可能强的完整性。这里的“robust”不等于有时用来指密钥承诺的“key robustness”。如果审批记录里只剩“robust”一词，最关键的区别已经丢失。

近义词是隐含假设的藏身处

nonce-misuse resilience 与 nonce-misuse resistance 看似同义，RFC 9771 明确说明并非如此。前者是在攻击者让其他位置发生 nonce 重复时，仍保护使用新鲜 nonce 的消息；后者还保护真正发生 nonce 重复的消息，但无法避免“同一 nonce 下重复同一明文”带来的固有泄漏。resistance 蕴含 resilience，反之不成立。

这个区别会直接改变测试计划。对 resilience 声明，要证明一次重复事故不会污染仍使用新鲜 nonce 的流量；对 resistance 声明，还必须描述重复 nonce 流量本身的机密性和完整性。RFC 8452 中的 AES-GCM-SIV 是标准化的抗 nonce 误用构造，但它不会把该性质转移给普通 GCM，也不能证明外围库正确处理密钥、消息上限或错误路径。

承诺性质也有类似陷阱。密钥承诺询问一份密文能否在不同密钥下有效；完全承诺还考虑不同 nonce、关联数据和明文。完全承诺蕴含密钥承诺，反向并不成立。当应用通过“解密成功”来发现租户、账户、会话或信封上下文时，这个区别就成为运营问题。上下文发现与承诺攻击研究 说明，多种有效上下文之间的歧义不只是术语之争。但任何承诺声明仍须写明构造、上下文编码、标签长度和安全模型；系统没有编码的绑定关系，单凭一个词无法补上。

从性质声明到性质凭据

性质凭据是一份精炼、带版本的证据对象。采购、安全工程、平台运营和事件响应团队都应能读懂它，而不必猜测彼此的假设。

第一项是精确性质及其 RFC 9771 类别。“具备 nonce 抗误用的机密性与完整性”是一项声明，“nonce 更安全”只是宣传。“可流式处理且验证成功前不释放明文”是一项接口声明，“支持流式”则不是。若机密性与完整性采用不同安全模型，两者都要列明。RFC 9771 要求：采用替代模型时，应有等价性证明；若并不等价，就应明确披露。

接着要冻结证据对象：算法与构造、参数集、标签长度、提供方或库、版本与构建、CPU 或加速器路径以及软件回退。针对设计的证明与针对二进制的符合性测试回答不同问题；凭据需要二者，也不能把它们混为一谈。

接口部分记录输入、输出释放时机、标签验证边界、分块顺序、取消和错误语义，并说明 nonce 与关联数据由谁构造。失败解密究竟不输出、输出缓冲内容、输出部分内容，还是在调用方已经行动后才报错，这些都不是实现琐事，而是在决定部署处于哪一个安全模型。

负面测试应从性质生成，而不是复制通用密码检查表。视声明而定，测试可以覆盖 nonce 重复、错误密钥、被改动的关联数据、跨上下文密文、截断或伪造标签、分块乱序或重复、提前输出、进程回滚、快照恢复、计数器耗尽、密钥阶段转换，以及软件与卸载路径不一致。负面测试通过只能证明被观察到的行为，不等于形式化证明；形式化证明也不代表 API 实现了其前提。

密钥生命周期部分记录生成与派生、密钥身份、nonce 与序列号作用域、并发规则、使用上限、轮换、销毁、备份恢复和多用户聚合。RFC 8645 描述了重密钥机制，但具体部署仍需证明采用了哪个触发条件、新旧状态如何重叠。当提供方版本、卸载路径、nonce 分配器、持久化模型或轮换策略改变时，凭据应到期重验。

最后，协议集成补上原语与线路之间的证据。TLS 1.3 从序列状态构造记录 nonce；QUIC 又加入包编号和密钥阶段行为。需要检查重试与重放路径、故障恢复、迁移、记录分帧、转录或上下文绑定、对端互操作，以及硬件终止是否保留同样的失败契约。算法名称处于这个系统之内，却不能描述整个系统。

买方现在可以提出的要求

RFC 9771 让一项精确要求成为可能：“对于你所声称的每项非常规 AEAD 性质，请给出精确安全模型、适用的实现与版本、维持其前提的 API 行为、检验其边界的负面测试、密钥生命周期控制，以及覆盖到的协议路径。”

供应商回答某项性质不支持、只适用于一条路径，或在某种失败模式下尚未证明，都是有价值的答案。它们建立了一道可定价、可监控、可复查的边界。危险的是没有负责人、没有到期时间的性质名称，因为它会把有条件的研究结论变成永久的组织记忆。

来源