3DES 曾经是 DES 的安全替代品：它把有效强度从 56 位提升到约 112 位，解决了密钥太短的问题，同时完全兼容已有的 DES 实现，迁移成本很低。在 AES 普及之前，它是金融、支付和通信领域的主力算法。但从 2017 年起，主流标准组织开始陆续宣布弃用 3DES，到 2023 年 NIST 正式将其移出可用算法列表。
弃用的原因不是密钥强度
首先要澄清一点：3DES 的 112 位强度本身并没有被攻破。
2^112 次运算仍然远超现实算力，没有公开的攻击能实际破解三密钥 3DES 的密钥。所以如果只看密钥强度，3DES 似乎还能用很多年。
它被弃用的原因在其他地方：分组长度太小，以及性能太差。
分组长度带来的硬伤
3DES 的分组只有 64 位，这一点继承自 DES，三倍运算并没有改变它。
64 位分组意味着加密过程中产生的中间值最多有 2^64 种可能。按生日问题，当同一个密钥下加密的数据量达到约 2^32 个分组时，中间值出现碰撞的概率就显著上升。2^32 个分组按每块 8 字节计算，大约是 32 GB。
32 GB 在现代场景里并不算大。一条高流量的长连接、一次批量数据传输、一段长时间的会话，都可能累积到超过这个量级。一旦发生碰撞，攻击者就能从中恢复部分明文信息。
2016 年公开的 Sweet32 攻击把这个问题从理论变成了实际可行的攻击路径。它针对的正是 64 位分组密码在长连接场景下的碰撞风险，通过持续传输大量数据触发碰撞，进而推断会话中的敏感信息。这个攻击影响的不只是 3DES，还包括所有 64 位分组的算法。
关键在于：这个问题无法通过加长密钥解决。密钥再长，分组长度还是 64 位，碰撞边界不变。所以 3DES 的 112 位强度在这种攻击面前提供不了保护。
性能也是实际问题
除了安全性，3DES 的效率在现代硬件上明显落后。
3DES 要做三次 DES 运算，而 DES 的轮函数设计是针对上世纪七十年代的硬件优化的，在现代 CPU 上效率不高。相比之下，AES 有专门的硬件指令（AES-NI），可以在极少的时钟周期内完成一个分组的加密。
实际测量中，3DES 的软件实现通常比 AES 慢三到六倍。在高并发、大数据量的场景里，这个差距会直接转化为服务器成本——需要更多的机器来处理同样的流量。
还有一点：3DES 的分组是 64 位，AES 是 128 位。这意味着处理同样大小的数据，3DES 需要更多的分组数量，进一步放大了性能差距。
弃用的时间线
标准组织的动作是渐进的，给了行业较长的迁移窗口。
2017 年前后，主流浏览器和 TLS 库开始移除对 3DES 密码套件的支持，因为 Web 流量是最容易触及 32 GB 边界的场景之一。同期，NIST 发布指南，建议在 2023 年底之后不再使用 3DES 加密超过特定数据量的数据。
2023 年，NIST 正式将 3DES 从可用算法列表中移除，理由是 64 位分组的安全边界已经被实际触及。
需要说明的是，弃用不等于「立刻不能用」。大量存量系统——特别是金融领域的 ATM 网络、IC 卡支付、部分专网通信——仍在运行 3DES。这些系统的迁移涉及硬件更换和协议升级，周期很长，所以实际退役会持续很多年。
迁移时的注意点
如果要把 3DES 迁移到 AES 或 SM4，有几处参数需要重新约定。
分组长度从 64 位变成 128 位，所以 IV 长度从 8 字节变成 16 字节。NoPadding 模式下，对数据长度的对齐要求也从 8 字节整数倍变成 16 字节整数倍。
填充方式可以保持不变（PKCS#7 是通用的），但要注意不同实现对填充命名的差异。
密文的长度会变化，因为分组变大后填充的粒度变了。如果密文存在固定长度的数据库字段里，需要先确认新长度是否超出。
最重要的是，迁移过程中新旧数据会并存。合理的做法是保留旧算法用于解密历史数据，读取后立即用新算法重新加密存储，逐步完成数据迁移。
检查清单
- 3DES 的 112 位强度没有被攻破，弃用原因不在密钥长度
- 64 位分组导致约 32 GB 数据量下就有碰撞风险，且无法靠加长密钥解决
- Sweet32 攻击把 64 位分组的碰撞风险变成了实际可行的攻击
- 3DES 缺少硬件加速，性能比 AES 慢数倍，成本影响明显
- NIST 在 2023 年正式移除 3DES，浏览器与 TLS 库在 2017 年前后已开始停用
- 迁移时注意 IV 长度从 8 字节变为 16 字节，密文长度与存储字段也要核对