摘要

  • RFC 3394 把 n 个 64 位密钥数据块封装成 n+1 个密文块：独立的完整性寄存器经历六遍混合，最前面的额外块是变换后的状态，并非被动填充。
  • 解封只有在恢复出的寄存器符合预期初始值时才能返回密钥数据；这项凭据检查密码包的一致性，却不证明发送者身份、授权、保管、鲜活性或密钥后续可用。

普通包裹在打包后会变大，多出的空间常被当作包装材料。RFC 3394 的额外块却不是无关紧要的外壳。它与密钥数据一起穿过整个机械过程，最后又站在出口，决定里面的字节究竟是候选值还是可以交给调用者的密钥。

这份 Informational RFC 于 2002 年 9 月发布，把 NIST 的 AES Key Wrap 规范带入互联网标准记录。文档对来源很坦率：主体文字来自 NIST 早期规范，关于安全性的断言属于美国政府，而不是 RFC 作者的独立声明。它提供的是可复现的变换，而非重新发现密码学。

“密钥数据”的范围比一把 AES 密钥更宽，可以是一把密钥、多把密钥或伴随信息。用于封装的 KEK 可以是 AES 支持的 128、192 或 256 位密钥。被保护数据先分成 n 个 64 位块，n 至少为二；输出则固定为 n+1 个 64 位块。

多出的块来自状态结构。明文进入 R[1] 到 R[n]，另有一个 64 位寄存器 A 从初始值开始。算法对整组 R 做六遍处理，总共执行 6n 次 AES。每一步把 A 与一个 R 块拼成 128 位输入；输出下半部写回该数据寄存器，上半部与计数器 t 异或后成为新的 A。

最后的 A 成为密文 C[0]，其后才是各个变换后的 R。因此，首块不是加密完成后为了凑长度而添的字节。它接触过每个数据块与每个计数位置。改动密文、使用错误 KEK、错用初始值合同或打乱顺序，都应让逆向过程无法恢复预期起点。

解封按相反方向执行。它先把 C[0] 装入 A，倒序撤销计数器和 AES 操作，得到候选明文寄存器。但候选值此时还不是可以返回的密钥。实现必须把恢复出的 A 与正确初始值比较。匹配才允许 R 越过边界；不匹配就必须报错，而且不得返回任何密钥数据。

默认初始值是八个十六进制 A6 组成的 64 位常量。RFC 3394 说，如果解封恢复出这个值，密钥数据仍损坏的概率为 2^-64；其他值一律拒绝。这个数字描述密码假设下的完整性检查强度，不是现实事故率，更不是发送者信誉或外围系统安全性的证明。

接受成功只回答一个窄问题：密文、KEK、算法变体与预期初始值在声明的强度下彼此一致。对称 KEK 无法由此指出是哪一个人或进程生成了密文，也不能证明封装获授权、包没有被重放、KEK 从未复制，或者恢复出的字节属于下游组件期待的算法与用途。

RFC 自己点出了寄存器之外最大的权力：KEK 保管。一旦 KEK 泄露，它保护的所有密钥数据都可能暴露。因为泄露的 KEK 仍能制造完全通过检查的封装，A 不可能证明 KEK 一直保密。同样，通过测试向量只能说明特定字节变换正确，不能证明无侧信道、错误路径一致、隔离有效或生产密钥得到妥善处理。

原始输入边界也不是偶然限制。RFC 3394 只接受至少两个 64 位块，并要求长度为 64 位的整数倍。文档已经预见其他完整性范围与非整块长度，于是为替代初始值留出接口，通用实现也应能灵活设置和检验它们。

RFC 5649 后来沿着这个接口扩展，而没有假装旧合同本来就覆盖所有输入。带填充的 AES Key Wrap 可以处理从一个字节开始的数据。它的替代初始值由 32 位常量和 32 位消息长度指示器组成；解封时检查常量、长度与块数是否相容，以及填充字节是否为零。短输入还使用专门的单块路径。声明改变了，凭据结构也随之改变。

这说明 A 是架构表面，不是魔法常量。原始形式主要证明固定块序列在所选 KEK 下经受了封装；带填充形式还携带长度断言。不同初始值可以承载不同应用合同。若把它们都压成模糊的“AES wrap”，恰好抹掉了寄存器原本要保存的证据。

后来的协议又增加名称层。RFC 3565 为 CMS 分配 AES 密钥封装标识符，JOSE 与 COSE 也在各自容器中定义 AES-KW 家族。标识符告诉解析器调用哪个变换和密钥长度，却不会把核心寄存器扩张成身份系统，也不能让原始版与填充版自动互换。

勘误记录进一步区分了稳定机制与印刷表达。三项 Verified 勘误修正文句和数组下标，Held 条目澄清索引并替换失效的历史链接。忠实实现应阅读这些修正，但它们没有改变六遍循环，也没有移动密钥释放边界。

按照 Lu Heng 的“最小初始规范”原则，RFC 3394 只固定独立实现互通所需的最少机械条件：块大小、状态、计数器、遍数、初始值检查与失败规则。KEK 保管、授权和协议绑定仍由真正拥有这些权力的系统决定。

“运行代码优先”则给出最后的举证责任。注册算法和通过样例不能证明生产实现会在失败时扣住明文、保护 KEK、避免泄漏或把结果绑定到正确用途。标准把应有凭据写得精确，实际系统必须证明这张凭据真的控制着出口。

RFC 3394 的额外寄存器很小，容易被误作开销。其实它承载了候选字节与已释放密钥之间的区别。但它的权力也止于此：它能说明密码包回到了预期形状，不能说明谁有资格取得内容、封装密钥是否仍可信，或门打开后发生了什么。

来源