解密三大主力算法：AES、RSA、SM4

聊到数据库加密，你绕不开三个名字：AES、RSA 和 SM4。

我刚开始接触数据库加密时，也搞混过。以为 RSA 地位最高，凡事都得用他。后来在一次金融客户的审计作业中栽了跟头——日志记录里的加密套件全是 AES-256，我却在用 RSA 的思路排查。你说尴尬不尴尬？

所以这一章，咱们把这三者的底细摸清楚。

算法家族的划分：对称 vs 非对称

说白了，加密算法就分两类：对称加密和非对称加密。判断标准很简单——加密和解密用不用同一把钥匙。

  • 对称加密：加密和解密用同一个密钥。典型代表就是 AES 和 SM4。优点是快，适合大批量数据。缺点是密钥分发是个麻烦事——你得想办法安全地把钥匙送给对方。
  • 非对称加密：加密和解密用不同的密钥——一对公钥和私钥。典型代表就是 RSA。优点是密钥管理方便，公钥随便给，私钥自己留着。缺点也很明显：慢，特别慢，不适合加密大量数据。

我记得在给一家电商平台做加密审计时，他们把所有数据都用 RSA 加密。结果是1GB的数据，加密用了两个多小时——完全扛不住业务压力。后来改成了混合加密，才把性能拉回来。

核心观点：数据库加密实战中，大量数据的加解密几乎只用对称算法。非对称算法只在密钥交换和数字签名场景里出现。

AES：全球通用的加密标准

AES，即高级加密标准，是当前应用最广的对称加密算法。我处理过的数据库加密审计案例中，八成以上都跟 AES 有关。

AES 有三个版本，核心区别就一个：密钥长度。

版本密钥长度轮数安全性等级
AES-128128 bits10 轮高，商业场景通用
AES-192192 bits12 轮更高，部分政府场景
AES-256256 bits14 轮极高，军工/金融标准

我的经验：在数据库加密领域，AES-256 是标配。我参与过的一个银行审计项目，监管方直接要求所有静止数据必须用 AES-256 加密，不接受 AES-128。所以你配置的时候，直接上 256 位，省得后续找麻烦。

AES 的工作模式也容易踩坑。常用的有 ECB、CBC、GCM。

  • ECB：最简单，但安全性最差。相同的明文块会产生相同的密文块——说白了就是有模式可循，攻击者很容易看出来。
  • CBC：引入了初始向量 IV，安全性大幅提升。但缺点是加密不能并行处理。
  • GCM：既是加密模式，又能验证完整性。我强烈推荐你在数据库加密中使用 GCM 模式——一次搞定加密和防篡改。

避坑指南：我曾经在一个审计项目中看到某系统用了 AES-ECB。明文中的用户手机号在密文里竟然可以清晰看出重复的字段模式。攻击者根本不需要破解密钥，光看数据块就能猜出哪个用户有数据。所以记住一句话：永远不要在生产环境用 ECB 模式。

RSA：非对称加密的标杆

RSA 的优势在于密钥管理简单，你不需要预先交换密钥。它在数据库加密中的典型用法是：

  • 加密小数据块：比如用来加密 AES 的密钥本身（这叫密钥封装）。
  • 数字签名：验证数据是否被篡改，证明数据来源。

但 RSA 有个硬伤——它能加密的数据长度受密钥长度限制。举个例子，你用 2048 位的 RSA 密钥，最多只能加密 190 字节左右的数据（因为还有填充开销）。你想想，就这点容量，加密一行数据库记录都不够用。

所以数据库审计日志里如果出现 RSA，通常不是用来加密了大量数据，而是用来保护 AES 的密钥。在日志里，你可能会看到类似这样的记录：

-- 用 RSA 公钥加密 AES 密钥（在数据库外部完成）
openssl pkeyutl -encrypt -inkey rsa_public.pem -pubin -in aes_key.bin -out encrypted_aes_key.bin

-- 在数据库中直接用对称密钥解密数据
SELECT AES_DECRYPT(ciphertext, '对称密钥') FROM users;

你看，真正的数据加密走的是 AES，RSA 只负责保护那把「钥匙」。这叫混合加密——性能和安全兼顾。

SM4：国密标准下的对称加密

SM4 是国家密码管理局发布的对称加密算法，跟 AES 的地位类似。如果你在国内做项目，特别是涉及政务、金融、央企等领域的，你迟早会遇到它。

SM4 的核心参数：

参数值
密钥长度128 bits
分组长度128 bits
轮数32 轮
工作模式ECB / CBC / CTR / GCM 等

嗯，这里要注意：SM4 的密钥长度是固定的 128 位。不像 AES 那样可以选择 192 或 256 位。不过在实际安全强度测试中，SM4 对抗常见攻击类型的表现并不输给 AES。

我个人习惯：在涉及国密合规要求时，我会优先推荐 SM4。别想着拿 AES 糊弄过去——有些行业审计专门查这个。我去年服务过的一家国有银行，加密审计不过关的原因就是：底层加密用了 AES 而不是 SM4。监管要求必须用国密算法，他们只能重做一遍。

三大算法的对比与选择

到底该用哪个？别急，我整理了一张表：

特点AESRSASM4
加密类型对称非对称对称
密钥长度128/192/2561024/2048/4096128
加密速度极快慢 (适合小数据)极快
典型场景大量数据加密密钥交换/签名国密合规场景
主要风险密钥管理不当密钥长度不足生态兼容性

你看懂了没？数据量大的时候走对称（AES/SM4），密钥分发和签名才走非对称（RSA）。

数据库加密选型决策流程 数据库加密选型决策表 数据规模大小？ 大量数据（>1KB） 小数据 / 密钥交换 选用对称加密 AES-256-GCM SM4-GCM（国密） 选用非对称加密 RSA-2048 或更高 注意：优先检查合规要求（国密/国际）

审计视角下的算法故障诊断

你在审计日志里看到的加密信息往往不完整。比如只记录了「使用 AES 加密」，但没告诉你具体的工作模式和密钥长度。这时候怎么查？

我的方法是：

  1. 看日志上下文：有些数据库会在会话建立阶段输出加密协商过程。比如 MySQL 的审计日志里会包含 SSL_CIPHER 字段——里面可以挖出完整算法信息。
  2. 检查配置文件：数据库的加密参数大多写在配置文件里。比如 PostgreSQL 的 ssl_ciphers 参数。我习惯直接去服务器上 grep 一下，比猜更靠谱。
  3. 做测试加密：如果还看不出来，就构造一条已知明文的数据，等它加密完成后对比密文长度和特征。比如 AES-128 的密文比明文最多大一个分块长度。RSA 的密文长度则固定等于密钥长度。

举个例子，假设审计日志里显示密文长度是 128 字节，那大概率是 AES-128 加密产生的（因为密文是 8 个 16 字节的分组）。如果是 256 字节的密文，可能就是 AES-256 或者 RSA-2048——这时候你需要结合上下文判断。

实用技巧：我排查数据库加密故障时，第一个动作就是查 openssl speed 测速结果。如果服务器上的 AES 吞吐量异常低，大概率是硬件加速没开。配置好了性能能翻好几倍。

选型建议：别让算法成为你的瓶颈

讲到这里，你应该能看出门道了。选算法不是选最好的，而是选最合适的。我给出的建议很简单：

  • 没有合规要求：直接用 AES-256-GCM。速度快、安全性高、生态支持好。
  • 有国密要求：上 SM4-GCM。别犹豫，合规比性能更重要。
  • 需要密钥交换或身份验证：套用 RSA-2048 或 RSA-4096。注意，密钥长度不能低于 2048 位——1024 位的 RSA 已经被学术界证明不安全了。

你想象一下，数据库加密就像是给你的数据穿铠甲。AES 和 SM4 是贴身软甲——灵活、防护好。RSA 是门外的盾牌——专门挡大块头的攻击。三者配合使用，才能让你的数据库真正固若金汤。

好了，这一章的内容就到这里。记住今天讲的三个名字，你以后在任何数据库加密场景里都能找到自己的路。

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