对称加密算法开销分析：AES-128/192/256
说到对称加密，AES 几乎就是事实标准。你在网上看到的 TLS、SSH、IPsec，但凡涉及加密通信，底层大概率跑的都是 AES。但问题来了——AES 有 128、192、256 三种密钥长度，到底选哪个？
老实说，我入行头两年根本不在乎这些。项目经理说用 AES-256 我就用 AES-256，反正加一个密钥长度又不会死。结果有一次在嵌入式设备上跑，128 位还能每秒处理几十兆，换了 256 位直接掉到个位数。从那以后，我再也不敢无脑选最大密钥长度了。
咱们今天就把 AES 三种变体的开销拆开看。你想想看，它们本质上都是 10、12、14 轮迭代，多出来的那几轮到底值不值？
1. 密钥扩展与轮数差异
AES 的核心运算叫「轮函数」。每一轮要做 SubBytes、ShiftRows、MixColumns 和 AddRoundKey。密钥长度的差异，直接决定了轮次数量：
| 算法 | 密钥长度（bit） | 轮数（Rounds） | 子密钥数量（10 字节/轮） |
|---|---|---|---|
| AES-128 | 128 | 10 | 11 |
| AES-192 | 192 | 12 | 13 |
| AES-256 | 256 | 14 | 15 |
多出来的轮次意味着什么？就是每次加密/解密都要多执行 2 到 4 组 SubBytes+ShiftRows+MixColumns 计算。我在一个软件实现的项目里测过：AES-256 比 AES-128 慢大约 40%～60%，具体取决于处理器是否支持 AES-NI 指令集。
2. 加密吞吐量实测对比
咱们直接看一组桌面级 CPU（支持 AES-NI）上的典型数据。单位是 MB/s：
| 操作 | AES-128 | AES-192 | AES-256 |
|---|---|---|---|
| ECB 模式加密 | 2800 | 2400 | 2100 |
| CBC 模式加密 | 2700 | 2300 | 2000 |
| GCM 模式加密 | 2600 | 2200 | 1900 |
能看到 AES-256 比 AES-128 慢了 25% 左右。而 AES-192 只慢了约 10%～15%，是个不错的中间点。
我个人的习惯是：对于非核心机密数据（比如普通 API 通信），用 AES-128 就够了。真正需要长期保护的数据（比如金融核心账户信息），才考虑 AES-256。AES-192 嘛……说实话，我在项目里很少用。不算是标准普适选择，但某些合规要求会指定它（比如某些政府项目）。
3. 安全性边界：别为了心理安慰多花性能
很多人觉得“格数越大越安全”，但密码学不是叠被子。针对 AES 的最有效攻击目前是穷举，没有实际可行的代数攻击。128 位密钥的暴力破解需要 2¹²⁸ 次尝试——以目前全球算力算，几十年都破不了。
量子计算出现之后，Grover 算法可以把对称密钥搜索减半。但即使这样，AES-128 仍然有 2⁶⁴ 次搜索的强度，远高于当前可行范围。所以 AES-128 在可预见的未来里，对绝大多数场景是安全的。
我帮你总结了一个选择原则：
- AES-128：通用场景，高性能需求，嵌入式/IoT 设备。能省就省。
- AES-192：中间态，除非合规明确要求，否则没必要。
- AES-256：最高安全等级，密钥派生、长期静态数据保护，或者客户有 SOG-IS / FIPS 认证要求。
4. 实际项目中的实现细节
你以为选好密钥长度就完事了？太天真了。我见过最离谱的一个 bug，是某开发者在 AES-256 的密钥扩展里用了错误的多项式，结果解密出来的数据前 16 字节是对的，后面全是乱的。查了三天才定位到。
另外，即使算法本身没问题，实现方式也会造成巨大开销差异：
- 纯软件实现：查表法（T-table）能用 8KB～16KB 内存换取 2～3 倍速度提升。但在微控制器上，这个内存开销可能不可接受。
- 硬件加速（AES-NI）：一条指令完成一轮加密，吞吐量能上 GB/s。这种情况下 AES-256 和 AES-128 的实际差异很小（约 10%～15%）。
- 嵌入式硬件 IP：很多 SoC 内部有对称加密引擎。我曾在一个车规芯片上遇到过——AES-128 吞吐量 1Gbps，AES-256 只有 600Mbps。原因就是引擎设计时只给了 128 位全流水线，256 位必须重入两次。
openssl speed -evp aes-128-cbc aes-256-cbc 就能拿到本地机器的实际增益。我每次都这么干，5 秒钟出结果，不纠结。
5. 上面这些关系，画成一张图更清楚
下面这张图总结了 AES 三种密钥长度的核心权衡点。左边是密钥长度，右边对应开销和安全性，中间用箭头连接。你可以理解为“密钥越长 → 轮次越多 → 处理时间更长 → 内存/功耗更高 → 安全性更强”。这条链上每步取舍都很清楚。
6. 实践：代码里怎么快速测试开销？
我直接用一段 Python 演示——实际项目中你可能用 OpenSSL 或者 crypto 库，但原理一样：
import time
import os
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
def bench_aes(key_len):
key = os.urandom(key_len // 8)
iv = os.urandom(16)
plaintext = os.urandom(1024 * 1024) # 1MB
cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
encryptor = cipher.encryptor()
t0 = time.perf_counter()
for _ in range(100):
encryptor.update(plaintext)
t1 = time.perf_counter()
return (t1 - t0) / 100
for bits in [128, 192, 256]:
elapsed = bench_aes(bits)
print(f"AES-{bits}: {1024 / elapsed:.1f} MB/s")这条代码跑完，你就能直观看到你目标机器上 AES-256 到底亏了多少。我一般用这个结果来跟产品经理谈性能预算——有数字比空口说“慢”有说服力多了。