对称加密算法：AES、DES、3DES、SM4 的原理与选型

说到对称加密，很多新人第一反应就是「用同一个密钥加密和解密」。没错，工作原理就这么简单。但真正落地时，你会发现算法选型是个大坑。我今天就从实际项目角度，把几个主流算法掰开揉碎了讲一遍。

DES —— 过时的老兵

DES 是 Data Encryption Standard 的缩写，56 位密钥长度。我在 2015 年接手过一个老系统，底层用的就是 DES。当时客户要求做渗透测试，结果不到半小时就被暴力破解了。56 位密钥在现代算力面前基本等于裸奔，所以现在只建议在研究或向后兼容时用。

3DES —— 补丁式的过渡方案

说白了，3DES 就是用 DES 加密三次，密钥长度变成 112 位或 168 位。安全性确实提升不少，但性能太差。我记得有一次处理百万级日志记录，3DES 的吞吐量比 AES 慢了将近 5 倍。而且它已经被 NIST 正式废弃——2023 年后不再作为推荐标准。

你想想看，一个补丁打了二十多年，也该退休了。除非维护遗留设备，否则别碰。

AES —— 当今的王者

AES 就是高级加密标准，密钥长度支持 128、192、256 位。我个人习惯首选 AES-256-GCM，因为 GCM 模式自带认证，能防止篡改。硬件加速也很完善，Intel 的 AES-NI 指令集能让加解密速度突破 1GB/s。

为什么 AES 是王者？它经过了 NIST 严格筛选，抗差分攻击、线性攻击能力都很强。我在金融项目里用 AES-128-CBC 配合 HMAC，安全性和性能都很好。

// 示例：OpenSSL 使用 AES-256-GCM 加密
#include <openssl/evp.h>
int encrypt(unsigned char *plaintext, int plaintext_len,
            unsigned char *key, unsigned char *iv,
            unsigned char *ciphertext, unsigned char *tag) {
    EVP_CIPHER_CTX *ctx;
    int len;
    int ciphertext_len;
    ctx = EVP_CIPHER_CTX_new();
    EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, key, iv);
    EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len);
    ciphertext_len = len;
    EVP_EncryptFinal_ex(ctx, ciphertext + len, &len);
    ciphertext_len += len;
    EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag);
    EVP_CIPHER_CTX_free(ctx);
    return ciphertext_len;
}

SM4 —— 国密标准

SM4 是中国国家密码管理局发布的对称加密算法，分组长度 128 位，密钥长度也是 128 位。在国产化替代的浪潮中，我参与过几个政务云项目，强制要求使用 SM4。说实话，它的加解密速度跟 AES-128 差不多，但生态相对小众。

选型时要注意：SM4 的模式推荐用 CBC 或 GCM，不要用 ECB。ECB 模式会把相同明文加密成相同密文，这在日志保护中等于泄露模式——我曾经在项目里见过有人这么用，后来被审计发现了，紧急换模式。

算法横向对比

我把四个关键指标整理成了一张表，方便你做决策参考：

算法	密钥长度	分组大小	安全强度	推荐场景
DES	56 bit	64 bit	低（已破解）	不宜用于新系统
3DES	112/168 bit	64 bit	中（已过时）	仅遗留系统维护
AES	128/192/256 bit	128 bit	高	通用首选
SM4	128 bit	128 bit	高	国内合规要求

核心逻辑结构

下面这张图梳理了四种算法从原理到选型的完整脉络：

选型实践建议

在实际项目中，我一般按这个优先级来决策：

• 第一步：看合规要求。国内政府、金融项目通常强制用 SM4；跨国业务首选 AES。
• 第二步：看密钥管理成本。如果密钥数量多，优先选 GCM 模式，省去额外做 MAC 的麻烦。
• 第三步：看硬件支持。云服务器大部分都支持 AES-NI，用 AES 能获得硬件级加速；SM4 的硬件支持还在普及中。