对称加密算法性能基础

聊到加密开销，第一个蹦出来的就是对称加密。你想想看，大部分业务系统里，真正扛流量的就是这些算法。AES、DES、3DES，名字听着熟，但它们的性能差距有多大？什么时候该用哪个？这里头门道不少。

我个人习惯，先不看理论，直接压测看数据。我记得几年前做一个支付网关，网关层要对报文做实时加解密。用了3DES，结果压测时CPU直接飙到90%。换成AES后，同样的机器，CPU只用了30%。那会儿我才真正意识到——选对算法，比优化代码管用多了。

对称加密性能的核心维度

衡量一个对称算法快不快，不能只看吞吐量。我一般从下面几个角度来评估：

维度 说明
吞吐量（Throughput） 单位时间内能加解密的数据量，单位 MB/s 或 Gbps
延迟（Latency） 单次加解密操作耗时，影响业务响应时间
CPU 占用率 算法对处理器资源的消耗，多核环境下更关键
密钥建立时间 生成密钥或初始化开销，影响短连接场景
内存占用 密钥展开表、查表缓存等内存需求

说白了，这些指标直接决定了你的系统能撑多少并发。很多时候，我们只盯着算法强度，忽略了性能代价。

AES vs DES vs 3DES：一个时代的缩影

DES 是上世纪 70 年代的标准，56 位密钥。放到今天，破解它就像用钥匙捅开一把生锈的锁——不费劲。我当年刚入行时，还见过一些老系统用 DES，后来全强制升级了。

3DES 是对 DES 的修补，执行三次 DES，密钥长度变成 112 或 168 位。但代价呢？加解密速度只有 AES 的十分之一左右。你想想看，同样的流量，别人用 AES 一台机器搞定，你用 3DES 得堆十台。这账谁都会算。

AES（Rijndael）是 2001 年成为标准的。密钥长度支持 128、192、256 位。硬件加速指令（AES-NI）出来后，AES 的性能直接起飞。现在的 x86 和 ARM 芯片基本都内置了 AES-NI，软件层面几乎零开销。

一句话总结：从性能角度看，AES 全面碾压 DES 和 3DES。除非是维护遗留系统，否则请直接使用 AES-128（性价比最高）或 AES-256（安全性更高）。

性能对比数据（软件实现，未启用 AES-NI）

下面这组数据是在同一台 Intel Xeon 服务器上做的测试，纯软件实现，单位 MB/s。你可以直观感受差距：

算法 密钥长度 加密吞吐 解密吞吐 相对 AES-128 比值
DES 56 55 52 ≈ 1/10
3DES 168 18 17 ≈ 1/30
AES-128 128 560 530 1.0
AES-256 256 420 400 ≈ 0.75

你看，AES-128 比 3DES 快了不止 30 倍。即使 AES-256 因为多两轮运算慢了点，也远远甩开老算法。

AES-NI 带来的质变

为什么 AES 能这么快？硬件加速指令是关键。启用 AES-NI 后，AES 的吞吐可以接近内存带宽。我测过，单核 AES-128-GCM 在 3GHz 的机器上轻松突破 2 GB/s。这什么概念？你流式加密一个 4K 视频，基本无感。

小贴士：判断你的 CPU 是否支持 AES-NI，Linux 下执行 grep aes /proc/cpuinfo，有 aes 标记就表示支持。大部分云服务器默认开启了。

模式选择对性能的影响

同样用 AES，不同模式性能差很多。ECB 最快但不安全，不推荐。CBC 需要顺序执行，很难并行。GCM 和 CTR 可以并行加解密，配合硬件加速能跑满带宽。

我在项目中遇到过一个问题：用 AES-256-CBC 加密大文件，单线程太慢。后来改成 AES-128-GCM，开启多线程分段加密，吞吐量翻了 8 倍。所以，不要只看算法，也要看模式。

一个简易的性能测试代码（Python + pycryptodome）

这是我在本地跑过的脚本，你也可以试试：

from Crypto.Cipher import AES, DES, DES3
import time, os

def bench(name, cipher_class, key_len, data):
    key = os.urandom(key_len)
    cipher = cipher_class.new(key, cipher_class.MODE_ECB)
    start = time.perf_counter()
    for _ in range(1000):
        cipher.encrypt(data)
    end = time.perf_counter()
    print(f"{name}: {(1000 * len(data) / (end-start)) / 1024 / 1024:.2f} MB/s")

data = b'A' * 1024 * 1024  # 1MB
bench("AES-128", AES, 16, data)
bench("DES", DES, 8, data)
# DES3 需要特殊 key 长度
bench("3DES", DES3, 16, data)

跑一下你会发现，AES 的耗时远小于 DES 和 3DES。不过要注意，ECB 模式不安全，实际生产多用 GCM 或 CBC 配合 HMAC。

警告：千万不要在生产环境使用 ECB 模式。它把数据切成独立块加密，相同明文块会输出相同密文块，容易泄露模式信息。我曾经在日志里看到有人用 ECB 加密用户头像——结果能直接看出头像轮廓，非常危险。

对称加密性能对比流程图

下面这张图展示了我心中对称加密的性能层级与选择逻辑：

对称加密算法性能与选择决策图 对称加密算法 DES / 3DES（已被淘汰） 性能差（只有AES的1/10~1/30） 密钥太短，易被暴力破解 AES（推荐使用） 硬件加速（AES-NI）支持 吞吐可达2GB/s+（单核） 密钥长度128/192/256位 模式选择 安全首选：GCM（认证加密） 高性能：CTR、GCM（可并行） 决策建议 新项目一律用AES-128-GCM；遗留系统若为3DES，优先迁移；避免ECB模式

这张图从左到右清晰展示了淘汰算法和推荐算法的对比，以及模式选择路径。我自己做架构评审时，常把这张图贴出来，让团队一目了然。

密钥粒度与性能的权衡

前面聊的都是算法级别，但实际工程里还有一个层次——密钥粒度。你想想，如果一个系统里所有用户共用一把密钥，性能上最优（一次加载，随便用）。但安全性呢？一个人密钥泄露，全盘皆输。

反过来，每个会话、每个文件都生成独立密钥，安全性拉满，但密钥管理的开销也拉满。你需要频繁调用随机数生成器、KDF，还可能涉及密钥派生，这些都是 CPU 开销。

我的习惯：一般我设计系统时，会采用分层密钥方案。主密钥用 AES-256，定期轮转；会话密钥用 AES-128，每次会话生成。这样既保证了基准性能，又能做到密钥泄漏影响最小化。

我曾经遇到过一个案例：某系统对所有请求都用同一个静态密钥，且放在前端代码里。结果被爬虫抓出来，整个数据库被脱走。嗯，这就是密钥粒度太粗的典型教训。后来我帮他们改成每用户一个派生密钥，性能只下降了不到 5%，但安全性提升了几个量级。

总结一句

对称加密的性能不是玄学。选对算法（AES）、开对指令（AES-NI）、用对模式（GCM）、设好粒度（分层密钥），你就能在安全和开销之间找到最佳平衡点。别迷信“多一重加密更安全”，也别为了性能裸奔明文。这个度，需要在实战里慢慢体会。

← 上一章 📖 返回目录 下一章 →