4、对称加密选型：AES-128 vs AES-256，GCM vs CCM vs CBC模式，硬件加速指令集（AES-NI）的影响

对称加密是受限设备上最核心的密码原语。你想想看，一个传感器节点可能只有几十KB的RAM，CPU主频不到100MHz，却要保证数据在无线传输中不被窃听或篡改。选错算法，要么跑不动，要么不安全。

我个人习惯把对称加密选型拆成三个维度：密钥长度、工作模式、硬件支持。这三个点定下来，方案基本就成型了。今天咱们就一个一个掰开聊。

4.1 AES-128 vs AES-256：安全余量与性能代价

先说结论：在受限设备上，AES-128通常是更合理的选择。这不是说AES-256不好，而是你得算清楚这笔账。

我在项目中遇到过客户坚持要用AES-256，理由是“更安全”。结果在Cortex-M0+的芯片上，加密一个128字节的数据包花了将近2毫秒——对于每秒需要处理几百个包的网关来说，这个开销直接导致吞吐量不达标。后来换成AES-128，性能问题迎刃而解。

为什么AES-256比AES-128慢这么多？说白了，AES的轮数不同：

参数	AES-128	AES-256
密钥长度	128 bit	256 bit
轮数	10 轮	14 轮
子密钥生成	4 字/轮	4 字/轮（但密钥调度更复杂）
相对性能	基准 1.0x	约 0.6x - 0.7x
安全余量	足够（量子计算威胁除外）	更高（抗量子计算有一定余量）

这里有个关键点：量子计算对AES的威胁被夸大了。Grover算法确实能把密钥搜索复杂度从O(2^n)降到O(2^(n/2))，但AES-128的64位量子安全强度，在可预见的未来依然牢不可破。你想想看，现在最快的量子计算机连40位密钥都破解不了，担心AES-128被量子攻破，就像担心明天小行星撞地球一样——理论上存在，实际上不用焦虑。

4.2 GCM vs CCM vs CBC：模式选择决定安全边界

选完密钥长度，接下来是工作模式。这块坑特别多，我一个个说。

4.2.1 CBC模式——别用了，真的

CBC模式曾经是主流，但现在我强烈建议你不要在新设计中使用它。为什么？

• CBC只提供机密性，不提供完整性。攻击者可以翻转密文块，导致解密后的明文被可控地篡改——这叫“填充预言攻击”，我在一个老旧的车载固件升级模块里亲眼见过这种漏洞。
• CBC需要填充。PKCS#7填充在受限设备上容易引入侧信道风险，而且会浪费宝贵的传输带宽。
• CBC不能并行加解密。每个密文块依赖前一个块，硬件加速也很难发挥全部性能。

4.2.2 GCM vs CCM：谁是受限设备之王？

这两个都是认证加密模式（AEAD），同时提供机密性和完整性。但它们的性格完全不同。

特性	GCM (Galois/Counter Mode)	CCM (Counter with CBC-MAC)
核心算法	CTR模式 + GHASH（Galois域乘法）	CTR模式 + CBC-MAC
硬件加速友好度	极高（AES-NI直接加速GHASH）	中等（CBC-MAC需要串行处理）
并行度	加解密可完全并行	认证部分必须串行
实现复杂度	中等（GHASH实现需谨慎）	较高（CTR和CBC-MAC共用密钥需小心）
nonce长度	推荐12字节（96 bit）	7-13字节（通常用11字节）
短数据包效率	较好（额外开销约16字节）	较好（额外开销约8-16字节）
典型应用	WiFi、TLS、高速数据流	Zigbee、蓝牙、低功耗传感器

我个人习惯这样选：

• 有AES-NI硬件加速 → 无脑选GCM。GHASH的Galois域乘法在硬件里就是一个时钟周期的事，性能碾压CCM。
• 没有硬件加速，且CPU主频低于50MHz → 考虑CCM。CCM只用AES加密操作，不需要额外的域乘法器，纯软件实现更简单。
• 数据包小于64字节 → CCM可能更优。GCM的GHASH初始化开销相对固定，短包场景下CCM的认证开销更小。

4.3 硬件加速指令集（AES-NI）的影响

聊到性能，就绕不开AES-NI。这玩意儿对受限设备的影响，比你想象的大得多。

4.3.1 AES-NI到底加速了什么？

AES-NI是Intel在2010年引入的一组x86指令集扩展，后来AMD也跟进了。它用硬件实现了AES的四个核心操作：

• AESENC / AESENCLAST：加密轮函数
• AESDEC / AESDECLAST：解密轮函数
• AESIMC：逆列混合变换（用于解密密钥扩展）
• AESKEYGENASSIST：密钥扩展辅助

但别以为AES-NI只加速AES本身。它还能加速GCM模式中的GHASH——通过PCLMULQDQ指令做Galois域乘法。这才是真正的杀手锏。

我做过一组对比测试，在Cortex-A72（支持ARMv8 Crypto Extensions）上：

场景	纯软件实现	硬件加速	加速比
AES-128-CBC 加密	12.5 MB/s	185 MB/s	14.8x
AES-128-GCM 加密+认证	8.2 MB/s	172 MB/s	21.0x
AES-256-GCM 加密+认证	5.9 MB/s	128 MB/s	21.7x

看到了吗？GCM模式在硬件加速下的收益最大，因为GHASH的瓶颈被彻底消除了。

4.3.2 受限设备上的硬件加速现状

不是所有受限设备都有AES-NI。你得根据芯片选型来判断：

• 高端MCU（如STM32H7、i.MX RT系列）：内置AES硬件引擎，支持DMA自动加解密，性能可达100+ MB/s。
• 中端MCU（如ESP32、STM32F4）：有AES硬件加速器，但通常不支持GCM的GHASH加速，需要软件配合。
• 低端MCU（如STM32G0、EFM8）：没有硬件加速，纯软件实现AES，性能在1-5 MB/s级别。
• RISC-V平台：部分新芯片开始集成AES扩展指令，但生态还在完善中。

4.4 知识体系总览

下面这张图把对称加密选型的核心逻辑串起来了。你可以把它当作决策参考。

4.5 总结与实战建议

说了这么多，最后给你一个可以直接用的决策清单：

1. 默认选AES-128，除非合规要求强制AES-256。
2. 优先用GCM模式，前提是硬件支持AES-NI或ARMv8 Crypto Extensions。
3. 没有硬件加速时，CCM是稳妥的备选，但要注意nonce管理和短包效率。
4. 永远不要在新设计中使用CBC模式，除非你要兼容遗留系统。
5. nonce管理是GCM的生命线，用设备唯一ID + 单调计数器构造nonce，确保永不重复。
6. 密钥派生用HKDF，不要直接使用主密钥做加解密。