2. 对称加密算法在存储中的应用：AES、SM4 的加解密流程与密钥管理

对称加密，说白了就是加密和解密用同一把钥匙。你在存储系统里看到的绝大多数数据落盘加密，底层跑的都是它。我做了这么多年存储安全，可以负责任地告诉你：对称加密是存储安全的基石。今天咱们就聊聊两个最主流的选手——AES 和 SM4，它们的加解密流程长什么样，密钥又该怎么管。

2.1 为什么存储系统偏爱对称加密？

你想想看，存储系统每天要处理 PB 级的数据。如果用非对称加密，性能根本扛不住。对称加密的优势就三个字：快、省、稳。

速度快：硬件加速后，AES-NI 指令集能让加解密跑到几十 Gbps。
密钥短：128 位或 256 位就够了，不像 RSA 动不动就 2048 位。
实现成熟：从 Linux 内核的 dm-crypt 到硬件加密卡，生态非常完善。

我在项目中遇到过不少团队，一开始想用 RSA 加密大文件，结果发现 CPU 直接被打满。后来全换成了 AES-256-XTS，性能问题瞬间解决。嗯，这就是典型的选型失误。

2.2 AES 加解密流程：从字节到密文

AES 的全称是 Advanced Encryption Standard，它把数据分成 128 位（16 字节）的块，然后一轮一轮地处理。我习惯把它的流程拆成四个步骤：

密钥扩展：把用户输入的密钥（128/192/256 位）扩展成多轮子密钥。
初始轮：明文与第 0 轮子密钥异或（AddRoundKey）。
主循环轮：重复执行 SubBytes、ShiftRows、MixColumns、AddRoundKey。
最终轮：去掉 MixColumns，只做 SubBytes、ShiftRows、AddRoundKey。

解密流程就是反过来，把 SubBytes 换成 InvSubBytes，ShiftRows 换成 InvShiftRows，MixColumns 换成 InvMixColumns。说白了，就是逆向操作一遍。

核心要点：AES-128 需要 10 轮，AES-192 需要 12 轮，AES-256 需要 14 轮。轮数越多，安全强度越高，但性能也会下降。我个人建议存储场景至少用 AES-256。

下面这张图展示了 AES 加密的完整流程，你可以直观地看到数据是怎么被一层层“搅乱”的：

2.3 SM4 加解密流程：国密标准

SM4 是中国国家密码管理局发布的对称加密标准。它的结构和 AES 类似，但细节上有很多不同。我最早接触 SM4 是在一个政务云项目里，客户明确要求必须用国密算法。说实话，刚开始还有点抵触，但用下来发现性能其实不差。

SM4 的几个关键参数：

参数	AES-128	SM4
分组大小	128 位	128 位
密钥长度	128/192/256 位	128 位
轮数	10/12/14	32
S 盒	8×8 固定	8×8 固定（与 AES 不同）
密钥扩展	基于 Rijndael 密钥调度	基于 32 轮非线性迭代

SM4 的加解密流程非常对称——加密和解密共用同一个算法，只是轮密钥的使用顺序相反。这一点和 AES 不太一样，AES 的解密需要单独实现逆操作。我个人觉得 SM4 的设计更优雅，实现起来也更简单。

我的经验：SM4 在软件实现上比 AES 略慢，但差距不大。如果你有硬件加速（比如支持国密的加密卡），性能完全可以接受。我曾经在一个 SSD 控制器里同时实现了 AES 和 SM4，实测 SM4 的吞吐量能达到 AES 的 85% 左右。

2.4 密钥管理：存储安全的核心命门

算法再强，密钥泄露了也是白搭。我在存储安全领域摸爬滚打这么多年，见过太多因为密钥管理不当导致的数据泄露事故。密钥管理说白了就三件事：生成、存储、轮换。

2.4.1 密钥生成

密钥不能是人工输入的弱密码，必须用密码学安全的随机数生成器。我建议用硬件随机数生成器（HRNG），或者至少用操作系统提供的 /dev/urandom。

// 使用 OpenSSL 生成 256 位 AES 密钥
#include <openssl/rand.h>

unsigned char key[32];  // 256 位
if (RAND_bytes(key, sizeof(key)) != 1) {
    // 处理错误
    fprintf(stderr, "密钥生成失败\n");
    exit(1);
}

警告：千万不要用 rand() 或 time(NULL) 作为种子生成密钥。我曾经审计过一个项目，他们用 srand(time(NULL)) 生成密钥，结果密钥空间被压缩到了秒级，暴力破解只需要几分钟。

2.4.2 密钥存储

密钥存储有几个常见方案：

硬件安全模块（HSM）：最安全，密钥永远不出硬件。适合金融、政务等高安全场景。
密钥管理服务（KMS）：云上常用，比如 AWS KMS、阿里云 KMS。密钥由云厂商托管，你通过 API 调用。
本地密钥文件：简单但风险高。如果必须用，一定要加密存储，并且限制文件权限为 600。

我个人习惯用 HSM 存储主密钥，然后用主密钥加密工作密钥。这样即使工作密钥泄露，主密钥还在 HSM 里，攻击者拿不到。

2.4.3 密钥轮换

密钥不能一成不变。我建议的轮换策略：

密钥类型	推荐轮换周期	触发条件
主密钥	1 年	安全事件、人员变动
工作密钥	30-90 天	数据量超过阈值（如 1TB）
会话密钥	单次会话	每次连接

轮换时要注意：旧密钥不能立即删除，因为还有数据是用旧密钥加密的。你需要先解密再重新加密，这个过程叫密钥迁移。我曾经在一个项目中设计过在线密钥迁移方案，用了两周才把 100TB 的数据全部迁移完。嗯，那段时间真是加班加到怀疑人生。

2.5 工作模式选择：ECB 是魔鬼

AES 和 SM4 都只是分组密码，你需要选择工作模式来处理多块数据。我强烈建议：永远不要用 ECB 模式。

为什么？因为 ECB 模式下，相同的明文块会生成相同的密文块。这在存储场景里是致命的——攻击者可以通过密文模式推断出数据的结构。我曾经在一个客户系统里看到他们用 ECB 加密数据库，结果密文里能直接看出哪些行是空值，哪些行有数据。这跟没加密有什么区别？

存储场景推荐的工作模式：

XTS：磁盘加密的首选，Linux 内核的 dm-crypt 默认就是 XTS 模式。
GCM：带认证的加密，能同时保证机密性和完整性。
CBC：经典模式，但需要处理 IV 的随机性。

我的建议：新项目直接上 AES-256-XTS 或 SM4-XTS。XTS 模式专门为存储设计，支持随机读写，性能损失小。我在多个 SSD 和 HDD 加密方案里都用它，效果非常好。

2.6 避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路：

IV 重用：同一个密钥下，IV 绝对不能重复。否则密文会被破解。我曾经见过一个团队用计数器做 IV，结果计数器溢出后重复了，导致整个加密系统失效。
密钥硬编码：把密钥写在代码里是最大的安全红线。我审计过一个项目，密钥直接写在 config.h 里，还提交到了 Git 仓库。嗯，那场面真是惨不忍睹。
忽略认证：只加密不认证，攻击者可以篡改密文。存储场景里，GCM 或 XTS 模式自带认证，别偷懒。
性能测试不足：加密会带来性能开销。我建议在项目初期就做性能压测，看看加密对 IOPS 和延迟的影响。别等到上线了才发现性能不达标。

对称加密在存储中的应用，说复杂也复杂，说简单也简单。核心就是选对算法、管好密钥、用对模式。做到这三点，你的存储安全就有了坚实的基础。

📚 课程目录

2. 对称加密算法在存储中的应用：AES、SM4 的加解密流程与密钥管理

2.1 为什么存储系统偏爱对称加密？

2.2 AES 加解密流程：从字节到密文

2.3 SM4 加解密流程：国密标准

2.4 密钥管理：存储安全的核心命门

2.4.1 密钥生成

2.4.2 密钥存储

2.4.3 密钥轮换

2.5 工作模式选择：ECB 是魔鬼

2.6 避坑指南