DES和TripleDES信息泄露漏洞

2016年，信息泄SWEET32攻击曝光，露漏直接把Triple DES推上了审判台。信息泄攻击者利用64位分组密码的露漏生日悖论，在约32GB数据加密后就能碰撞出明文异或值，信息泄进而恢复出敏感信息。露漏这不是信息泄理论推演，OpenSSL和OpenVPN当时都紧急发了补丁。露漏DES和Triple DES的信息泄信息泄露漏洞，从来就不是露漏"会不会发生"的问题，而是信息泄"什么时候被利用"的问题。

DES的露漏分组长度只有64位，密钥表面上是信息泄56位（另外8位是奇偶校验，实际不参与加密）。露漏56位密钥空间在1970年代或许够用，信息泄但1998年电子前沿基金会用一台25万美元的机器，三天就暴力破解了DES密钥。更致命的是64位分组——根据生日悖论，当同一密钥加密的数据量接近2^32个分组（约32GB）时，出现分组碰撞的概率就超过50%。碰撞意味着两个不同明文分组产生了相同密文，攻击者可以推导出它们的异或关系，进而恢复明文。这就是SWEET32的核心逻辑。

Triple DES试图用"加密-解密-加密"三步走把有效密钥拉到112位或168位，但它没改分组长度。分组还是64位，碰撞问题原封不动地继承下来。换句话说，Triple DES把钥匙换成了更复杂的锁芯，门框还是那个一踹就开的旧门框。NIST在2017年正式建议弃用Triple DES，2023年后不再批准用于任何新用途。可现实是，大量金融系统、POS终端、甚至某些VPN还在跑3DES，因为迁移成本高，因为"还能用"。

我见过一个真实案例：某中型企业的IPsec VPN用3DES加密，运维觉得"3DES比AES老，但更稳"。结果流量一上去，超过30GB之后，隧道开始出现间歇性解密失败。日志里全是"bad decrypt"错误。他们以为是网络抖动，查了三天才发现是分组碰撞导致的重放或篡改检测误报。攻击者如果主动注入流量，完全可以在碰撞点做文章，提取出部分明文片段。这不是危言耸听，是密码学数学的硬约束。

DES和3DES的信息泄露漏洞，本质上是"分组太小"和"密钥太短"两个问题叠加。DES的56位密钥在今天用GPU集群几小时就能穷举。3DES的112位有效密钥虽然暂时扛得住暴力破解，但64位分组带来的碰撞攻击把安全边界压到了32GB数据量。32GB是什么概念？一条千兆网线跑满，不到五分钟就传完了。现代任何稍具规模的加密通道，几分钟就能突破这个阈值。

更麻烦的是，很多协议用3DES时还搭配CBC模式。CBC模式下，初始化向量（IV）如果可预测或重复，攻击者能直接进行选择明文攻击。SSL/TLS早期版本里的BEAST攻击就是利用CBC的IV弱点。3DES加CBC，等于把两个已知弱点绑在一起用。有些老系统甚至用固定IV，那基本等于把明文写在脸上。

修复方案不复杂：换AES。AES的分组是128位，生日悖论的安全边界拉到约256EB数据量，密钥长度128/192/256位随便选。迁移成本主要在硬件和遗留协议。POS终端换AES需要重新认证，某些工业控制协议栈写死了3DES。但继续用3DES，等于明知门框快塌了还不换门。我的判断是：任何还在用3DES加密超过1GB数据的场景，都应该立刻排期迁移。32GB的碰撞阈值不是遥远的天文数字，是几小时就能撞上的墙。