加密算法选型与性能权衡：AES-NI硬件加速、国密SM4性能对比、非对称加密的取舍

加密这事儿，说白了就是拿时间换安全。但存储系统里，IO路径本来就长，再加一层加密，搞不好性能直接腰斩。我见过不少团队，一上来就上最强加密，结果业务扛不住，又灰溜溜地降级。选型不是选最强的，是选最合适的。

AES-NI：硬件给你兜底

AES-NI 是 Intel 在 2010 年左右推的指令集扩展。它把 AES 加密的核心轮运算直接做成了 CPU 指令。你想想看，原来要几十条指令才能算完的一轮，现在一条就搞定。

我习惯在压测前先看一眼 /proc/cpuinfo 里有没有 aes 标志。没有的话，软件 AES 性能大概只有硬件加速的 1/5 到 1/10。特别是 GCM 模式，没有 AES-NI 加持，吞吐量惨不忍睹。

嗯，这里要注意：AES-NI 只加速 AES 算法本身，不加速模式运算。像 XTS 模式需要两次 AES 操作加一次 XOR，这部分还得靠 CPU 算。所以选模式时也要考虑。

SM4：国密不是不能打

SM4 是国家密码管理局发布的对称加密标准。很多人觉得国密性能差，其实是个误解。SM4 的轮函数设计比 AES 简单，单轮计算量更小。但 AES 有硬件加速，SM4 目前只能靠软件跑。

我在一个政务云项目里做过对比测试。同样的硬件平台，SM4-XTS 的吞吐量大约是 AES-NI-XTS 的 30%-40%。这个差距主要来自硬件加速，不是算法本身的问题。

非对称加密：别在数据路径上用它

非对称加密，比如 RSA、ECC、SM2，计算量比对称加密大几个数量级。RSA-2048 的签名操作大概要 1-2 毫秒，而 AES-256 加密 4KB 数据只要几微秒。差了 1000 倍。

我曾经见过一个架构，每次读写都做一次 RSA 加密。结果呢？IO 延迟从 1ms 飙到 50ms，业务直接炸了。非对称加密的正确用法是：只在密钥交换、数字签名、身份认证时用。数据加密，交给对称加密。

选型决策树

我一般按这个逻辑来选：

1. 有没有合规要求？ 有 → 走国密 SM4；没有 → 走 AES-256。
2. CPU 支持 AES-NI 吗？ 不支持 → 考虑 SM4（软件实现差距不大）；支持 → 无脑 AES。
3. 需要认证加密吗？ 需要 → GCM 模式；不需要 → XTS 模式（存储首选）。
4. 密钥怎么管理？ 非对称加密只用在密钥分发和签名上，别碰数据路径。

性能调优的几条实战经验

• 对齐缓冲区： AES-NI 对 16 字节对齐的缓冲区有额外加速。我习惯用 posix_memalign 分配 64 字节对齐的内存。
• 批量处理： 单次加密 4KB 比 512 字节快 3-4 倍。尽量合并小 IO。
• 避免频繁上下文切换： 加密操作尽量在同一个线程里完成，别跨核传递加密上下文。
• 密钥派生别用非对称： 用 HKDF 或 KDF，别用 RSA 去派生对称密钥，太慢。

加密选型没有银弹。AES-NI 是性能标杆，SM4 是合规底线，非对称加密是守门员。搞清楚你的场景，选对工具，性能和安全可以兼得。