那还是几年前的一个项目，用户登录接口被人摁在地上摩擦——暴力破解。但问题不在破解速度，而是我们用了ECB模式存密码（别学）。结果拖库后，相同密码的密文一毛一样，攻击者直接彩虹表走起。那次事故让我重新审视对称加密，看似简单，用不好就是灾难。这话题老生常谈？但你往下看，真不简单。
AES的“搅屎棍”艺术：SPN轮函数到底在干嘛
坦白说，第一次翻开《应用密码学》，看到AES的SubBytes、ShiftRows、MixColumns、AddRoundKey这四板斧，我脑子里冒出一个画面：洗牌。对，就是赌场里那种花式洗牌——先把每张牌换成另一张（S盒查表），再把一列牌左移几位（行移位），接着整列搅和你中有我（列混合），最后拍上一轮密钥。十轮、十二轮还是十四轮，取决于密钥长度。但核心就是扩散和混淆。香农老爷子在上世纪四十年代就说了，加密得让明文和密文之间的统计关系尽可能复杂。AES算是把这句话做到了极致。
再泼点细节。那个S盒，可不是随随便便的查表——它是有限域GF(2^8)上的逆元运算再叠加仿射变换。听着玄乎，说白了就是数学保证的非线性，防差分攻击。而列混合，用的是MDS矩阵，确保一个字节变化能搅动整列四个字节。轮密钥加最直白，但密钥编排（key schedule）也藏了心机：从原始密钥逐轮扩展，每一轮密钥都用前一轮密钥经过字旋转、S盒替换、轮常数异或生成。有人吐槽密钥编排安全性低于轮函数本身，但这么多年也没出过大纰漏。话说回来，这整套流程，时钟周期里跑的其实是代数和异或，硬件实现极其高效——这也为后面的AES-NI埋下伏笔。
无AES-NI不加密：硬件加速的性能碾压
先甩数据。在我那台老掉牙的Intel Xeon E3-1230上跑OpenSSL speed测试，AES-128-CBC纯软件实现（no-asm），吞吐量惨淡：约莫580 MB/s。当时心想，就这？再来，开启AES-NI硬件支持，数字直接蹿到3.2 GB/s。五倍多提升。更不用说延迟——加密1KB小块，软件要几个微秒，硬件直接干到纳秒级。现代CPU的AES指令集，比如Intel从Westmere架构开始加入的AES-NI，提供了aesenc、aesenclast这类单轮加密指令，一轮只需3-5个周期。对于GCM模式，还有PCLMULQDQ指令加速伽罗瓦域乘法。没这些，你试试让一台服务器撑起几万TPS的TLS？门儿都没有。
工程美学在哪？在于把密码学的数学优雅地映射到硅片。你瞧，AES的轮函数正好匹配处理器流水线，指令集设计者把状态矩阵塞进XMM寄存器，128位数据并行处理。这比任何黑科技算法优化都实在。记得有一次做手机端视频流加密，起初为了省电用软件AES，帧率掉成狗。切到ARM的AES扩展指令，功耗反而降了——因为CPU不用累死累活算。这就是硬加速的不可替代性：省下来的cycles能去干正事。
三个让我血压飙升的坑
坑1：ECB比明文还可怕
前面提了，ECB模式把相同明文块加密成相同密文块。你传一张图片，企鹅轮廓依旧。这不是加密，是打码。但很多新手图省事，直接用库默认值，尤其在数据库字段加密时。正确姿势：AES-GCM（常与TLS 1.3绑定），或者AES-CBC配合HMAC（但次序要对——先加密再MAC）。记着，现代应用必须带认证加密，别只保密不管完整性。
坑2：IV/Nonce复用——GCM剥皮刀
GCM模式好用，速度快，不用padding。但它有个死穴：同样的密钥+同样的nonce，那就等着被虐。攻击者能算出哈希子密钥，然后伪造消息。我见过一个监控系统，重启后nonce清零，结果就出事了。解决方案很直接：用96位随机nonce（概率保证碰撞极低），或者用计数器，但务必与密钥绑定且在重置密钥前绝对不重复。如果实在担心，就用AES-GCM-SIV吧，多一层保险。
坑3：随机数生成器弱得像纸
密钥生成、IV生成，全得靠随机数。可别用time(NULL)当种子。还记得2010年Debian那个漏洞吗？弱随机数导致SSL私钥可预测。教训是血淋淋的。如今，Linux下直接用/dev/urandom，Java用SecureRandom，别自己造轮子。特别是在容器化环境里，熵源可能不足，卡启动？用haveged或者rng-tools喂熵，或者从宿主机透传。别嫌麻烦，真出了事，加班加的你想砸显示器。
写到这里，忽然想起去年帮一个团队修加密库的事。他们的AES实现自己写了个密钥调度，结果一轮过后差分特征就显著了。我猜他们八成没看FIPS 197附录。所以，别重复造轮子，除非你真懂。
对称加密不是黑盒，它是精密计算和硬件通力合作的艺术。下次你用curl访问https的时候，不妨想想那些在CPU里翻腾的异或和S盒，还有曾经踩过的那些坑。嗯，也许这就是工程师的浪漫吧。
