📚 课程目录第4章对称密钥轮换中的边界变化

4. 对称密钥轮换中的边界变化：加密上下文切换归纳总结

密钥轮换不只是换一把钥匙那么简单。每次换密钥，加密上下文——算法、参数、IV、认证标签——都可能跟着变。边界一乱，解密就炸。

  核心观点：加密上下文决定了密文的“形状与尺寸”。轮换时如果上下文变了，数据边界就会漂移，接收方必须知道如何对齐新边界。

4.1 加密上下文包含哪些“边界”

说白了，一个加密上下文就是加密操作的全部状态。我把它拆成三块：

算法族与模式——AES-128-CBC vs AES-256-GCM，块大小、流模式都不同。
参数集——IV/Nonce 长度、填充方案、认证标签长度。
密钥派生因子——KDF 盐、计数、上下文绑定。

轮换时，这三块里任何一项变化，都会导致密文边界移位。你想想看，旧系统用 CBC + PKCS7 填充，新系统换成 GCM 不带填充——密文长度直接少一个块，解密程序不识别，数据就全乱了。

我的习惯：每次轮换前先画一张“加密上下文对比表”，把新旧两套参数逐项列出来。哪项不同就标红，然后决定如何兼容。

4.2 边界变化的典型场景

我在项目中遇到过几个最常踩的坑：

场景	旧上下文	新上下文	边界变化
AES-128-CBC → AES-256-CBC	IV 16 字节，PKCS7 填充	IV 16 字节，PKCS7 填充	仅密钥长度变，密文边界基本不变
AES-128-CBC → AES-128-GCM	IV 16 字节，填充 1~16 字节	Nonce 12 字节，无填充，附加 16 字节标签	密文长度减少一个块，尾部多标签
AES-128-GCM → AES-256-GCM	Nonce 12 字节，标签 16 字节	Same parameters	仅密钥长度变，边界不变
DES-64-CBC → AES-128-GCM	块 8 字节，IV 8 字节，填充	块 16 字节，Nonce 12，无填充，标签	几乎全变了，必须显式标记上下文

注意看第二行：从 CBC 切到 GCM，块大小相同但填充和认证方式全变了。密文的实际载荷长度从“原始数据 + 补位”变成“原始数据”，尾部还多出一串认证标签。接收端如果还按旧方式切分，标签会被当成数据，认证失败。

我曾经踩过的坑：有一次做云密钥轮换，把 GCM 换成 CCM，忘了更新解析代码的 IV 长度（GCM 用 12 字节，CCM 用 7~13 字节可变）。结果所有 12 字节 IV 的前 5 个字节被当成随机数，后 7 个字节当 Nonce——解密出来的前 5 字节全是乱码。查了一整天才发现是边界对齐问题。

4.3 处理边界变化的三种策略

实战中我总结出三条路，按可靠性排序：

版本化封装——每条密文前面加一个元数据头，标明加密上下文版本。解码时先读版本，再查表选解析方式。最稳，但会多出 4~8 字节开销。
上下文固定——轮换时只换密钥，不换模式/参数。边界不变，代价是长期绑定旧参数，可能放弃新算法的安全优势。
带内协商——通信双方用协议字段交换上下文 ID。适合连接型场景，但处理逻辑复杂，容易出现竞态条件。

我个人偏好第一种，因为干净。你想想看，一条密文自带“说明书”，不管未来怎么换，老数据也能被正确解析。我曾经把项目中所有密文都加了个 2 字节的上下文 ID，后续轮换从未出过边界问题。

4.4 上下文切换的实现细节

假设你用版本化封装，数据结构大概长这样：

// 加密上下文元数据头（8 字节）
uint8_t  version;        // 上下文版本号（如 0x01）
uint8_t  flags;          // 位标记：0x01 = 有认证标签，0x02 = 使用 KDF
uint16_t iv_length;      // IV/Nonce 长度（字节）
uint16_t tag_length;     // 认证标签长度（GCM/CCM 非零）
uint16_t reserved;       // 保留，可存密钥 ID 或算法 ID
  
// 加密载荷
[IV/Nonce] (iv_length 字节)
[Ciphertext] (原始数据长度，无填充)
[Auth Tag] (tag_length 字节)

注意这里我特意把填充去掉了。如果旧上下文用 CBC + 填充，新上下文用 GCM，密文长度不一样，那旧数据在新上下文中就无法解密。所以版本化头必须带上原始上下文信息，让代码根据版本号选择正确的解密流程。

实现建议：把上下文版本和参数集做成一个全局注册表（Registry），轮换时注册新版本，旧版本只读。这样“切换代码”和“解析代码”分离，不容易出 bug。

4.5 边界变化的知识体系图

4.6 归纳总结：一条原则，两个检查点

做了这么多项目，我给自己定了一条铁律：

“轮换前，先对齐上下文；轮换中，保持边界可解释；轮换后，验证解密通顺。”

具体落地就两个检查点：

第一个检查点：新旧上下文的 IV/Nonce 长度是否一致？如果不一致，解析代码必须能按版本切换读取长度。
第二个检查点：认证标签或 MAC 是否存在/长度是否一致？如果新上下文多了标签，旧数据必须被标记为“无标签”，不能强行解析。

嗯，这里要注意：不要想当然以为“换密钥就只换密钥”。很多轮换失败案例，根源都在上下文边界上。我曾经见过一个团队花了一周排查解密失败，最后发现是 CBC 的 IV 和 GCM 的 Nonce 都写 16 字节，但 GCM 只取了前 12 字节——后端存储的 IV 多出 4 个字节的冗余，前端却按 12 字节读，前后差了 4 字节，所有数据都错位了。

又一个经验之谈：不要依赖默认参数。每次轮换都要明确写出加密上下文的所有字段。哪怕是“长度相同”也要显式指定。模糊就是 bug 的温床。

归根结底，边界变化不是什么高深理论，就是“数据格式说明书”的版本管理。你把上下文写清楚、存起来、解析时按版本走，问题就解决了大半。剩下的，无非是测试覆盖每个边界条件。