64 位分组长度带来了什么问题 - 极速工具箱

讨论 DES 为什么不安全时，几乎所有的注意力都集中在 56 位密钥上——密钥太短，可以被穷举。但 DES 还有另一个同样致命的问题，而且它不会随着密钥加长而消失：分组长度只有 64 位。这一点直接导致了 3DES 被提前淘汰，也让 AES 在设计时把分组长度定为 128 位。

分组长度决定什么

分组密码的工作方式是把明文切成固定大小的块，逐块加密。分组长度就是每块的大小，DES 是 64 位，也就是 8 字节。

在 CBC 这样的串联模式里，每块的加密都依赖前一块的密文。这些中间值（密文块）会作为后续运算的输入反复出现。分组长度决定了这些中间值可能取值的总数：64 位分组意味着中间值最多有 2^64 种可能。

当加密的数据量足够大时，这些中间值就会出现重复——而且重复的概率随数据量的增长呈平方级上升。这就是生日问题的典型表现：不需要穷举 2^64 种可能，只要大约 2^32 个样本，就有相当高的概率出现一次重复。

2^32 大约是 43 亿。换算成加密的数据量：每个分组 8 字节，43 亿个分组大约是 32 GB。

也就是说，用同一个密钥加密超过 32 GB 左右的数据，密文块出现重复的概率就会显著上升。对于现代的存储和传输场景，32 GB 是一个很容易达到的数字——一次全量备份、一段视频流、一条高流量的网络链路，都可能超过这个量级。

一旦密文块出现重复，攻击者就获得了信息：这两处明文不同（在 CBC 下相同的明文会产生不同的密文），但它们的中间状态发生了碰撞。利用这种碰撞，攻击者可以恢复部分明文信息。

2016 年公开的 Sweet32 攻击，正是针对 64 位分组密码的这一弱点。

它的思路是：让受害者在同一条加密连接上持续发送数据（例如通过一段包含大量重复内容的脚本持续请求），累计超过足够的数据量，触发密文块碰撞，然后利用碰撞推断出会话中的敏感信息（例如 Cookie 中的会话令牌）。

这个攻击的实际利用条件比较苛刻——需要维持长时间的高数据量传输，也需要攻击者能在网络中观察流量。但它清楚地说明了一件事：64 位分组的安全性边界是可以用实际手段触及的，不是纯理论问题。

Sweet32 影响的不只是 DES 和 3DES，还包括所有使用 64 位分组的密码（如 Blowfish、IDEA 等）。这也解释了为什么这些算法在现代协议里都被逐步淘汰。

把分组长度从 64 位提升到 128 位，中间值的可能取值从 2^64 变成 2^128。按生日问题计算，出现碰撞需要约 2^64 个分组，也就是约 2^67 字节——这个数据量远超任何实际场景的传输能力，因此碰撞在实际中不可达。

这就是 AES 选择 128 位分组的理由。同时也要注意，AES 的分组长度是固定的 128 位，而密钥长度可以选 128、192、256 位——分组长度决定碰撞边界，密钥长度决定穷举难度，两者解决的是不同的问题。

一个常见的误解是「AES-256 因为密钥更长所以分组也更大」。实际上 AES-128、AES-192、AES-256 的分组都是 128 位，差别只在轮数和密钥扩展。

如果系统里还在用 DES 或 3DES，有几点值得注意。

第一，限制单个密钥加密的数据量。如果无法立即更换算法，至少应该控制每个密钥处理的数据总量，定期轮换密钥。把数据量控制在碰撞边界之下，可以降低风险。

第二，优先在长连接场景更换算法。Sweet32 的利用场景是长连接上的持续数据传输，这类场景风险最高，应当优先迁移。

第三，迁移时注意分组长度变化带来的影响。DES 和 3DES 的分组是 8 字节，AES 和 SM4 是 16 字节。这意味着 IV 长度从 8 字节变成 16 字节，NoPadding 模式下对数据对齐的要求也变了。跨算法迁移时，这些参数都需要重新约定。

第四，不要把「换成 3DES」当成解决方案。3DES 解决了密钥太短的问题，但没有解决分组太小的问题。它被 NIST 弃用的原因，很大一部分正是 64 位分组带来的风险。