AES加密怎么用？

wen python案例 2026-07-21 3

从零读懂AES加密：原理、实战与避坑指南（2025最新版）

📚 目录导读

【开篇问答】AES加密到底怎么用？别被复杂术语吓到
【核心原理】一图看懂AES的加密工作流（128/192/256位区别）
【实战操作】四步上手：代码示例（含Python/Java/浏览器控制台）
【避坑必读】Key、IV、填充模式选择错误，加密等于白做
【安全问答】常见误区与行业最佳实践

1️⃣ 【开篇问答】AES加密到底怎么用？

Q：同事问我“AES加密怎么用”，我只会复制粘贴，能解释清楚吗？
A： AES（高级加密标准）是目前全球最通用的对称加密算法，从银行转账到微信聊天记录都在用它。使用AES加密只需要四个要素：明文、密钥、初始化向量（IV）、加密模式。 但90%的新手踩坑都因为“密钥和IV没有分清楚”，或者直接使用ECB模式（事实上NIST已建议弃用ECB）。

AES加密怎么用？

Q：我需要加密一段用户密码，用AES合适吗？
A： 不合适！ AES适合加密“结构化数据”（如文件、JSON字符串、数据库字段加密），而用户密码必须使用bcrypt或Argon2这种不可逆Hash算法，用AES加密密码是2025年最常见的“自以为是的安全漏洞”。

Q：AES 128/192/256到底选哪个？
A：对于99%的业务场景，AES-128足够安全（量子计算机成熟前），选择256位仅多在云端合规或对付“未来威胁”的场景（如金融核心交易），但注意：AES-256性能比128约慢40%，且部分老旧设备（如IoT芯片）不支持。

2️⃣ 【核心原理】一图看懂AES加密工作流

1 加密模式（Mode）决定安全性

模式	是否需要IV	并行性	安全性评价	适用场景
ECB	否	是	⚠️ 极其不安全（相同明文块产生相同密文）	坚决不推荐！
CBC	必须（16字节随机）	否	安全，但有IV篡改风险	文件加密、传统系统兼容
CTR	必须（随机nonce）	是	高效安全，推荐	流加密、网络协议（如TLS）
GCM	必须（12字节推荐）	是	推荐，自带完整性验证	Web API、现代标准

核心结论： 2025年的标准答案是AES-256-GCM（或AES-128-GCM），除非你必须兼容旧系统。

2 填充模式为什么重要？

问题： AES加密块大小固定为128位（16字节），若明文长度不是16的倍数，需要填充。
普通做法： PKCS7填充（最通用）；零填充（仅适用于文本数据）；ISO10126（已废弃）。
关键： GCM模式不需要填充（内部流模式），但CBC必须填充。

3️⃣ 【实战操作】四步上手：代码示例

1 Python（最推荐，自带库）

from Crypto.Cipher import AES
import os
def encrypt_aes_gcm(plaintext, key):
    # 步骤1：生成随机iv（12字节对GCM最理想）
    iv = os.urandom(12)
    # 步骤2：创建加密器（使用GCM模式）
    cipher = AES.new(key, AES.MODE_GCM, nonce=iv)
    # 步骤3：加密并生成认证标签（验证完整性）
    ciphertext, tag = cipher.encrypt_and_digest(plaintext.encode())
    # 步骤4：返回iv+密文+tag（顺序随意，但必须一起存）
    return iv + ciphertext + tag
# 调用示例（密钥必须是16/24/32字节）
key = os.urandom(16) # AES-128
encrypted = encrypt_aes_gcm("这是需要加密的数据", key)

2 Node.js / 浏览器控制台

const crypto = require('crypto');
function encrypt(text, key) {
    const iv = crypto.randomBytes(12); // GCM推荐12字节
    const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
    let encrypted = cipher.update(text, 'utf8', 'hex');
    encrypted += cipher.final('hex');
    // 获取认证标签（需要一起存储）
    const tag = cipher.getAuthTag().toString('hex');
    // 返回：iv:密文:tag 格式
    return `${iv.toString('hex')}:${encrypted}:${tag}`;
}
// 密钥必须是32字节（AES-256）
const key = crypto.randomBytes(32);

3 Java（标准库）

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
public byte[] encrypt(byte[] plaintext, byte[] key) throws Exception {
    byte[] iv = new byte[12];
    SecureRandom.getInstanceStrong().nextBytes(iv); // 安全随机
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"), 
                new GCMParameterSpec(128, iv));
    byte[] ciphertext = cipher.doFinal(plaintext);
    // 返回 iv+密文+tag(最后16字节)
    return ByteBuffer.allocate(iv.length + ciphertext.length)
           .put(iv).put(ciphertext).array();
}

4️⃣ 【避坑必读】Key、IV、填充模式选择错误，加密等于白做

1 密钥（Key）的绝对红线

错误： 直接写死字符串"AABBCCDDEEFF"作为密钥
✅ 正确： 密钥必须有足够熵（至少32字符随机字符），且存储在环境变量或密钥管理服务（如AWS KMS / 阿里云KMS），不要硬编码。
错误： 用户输入的密码直接作为密钥
✅ 正确： 使用PBKDF2或Argon2将用户密码导出为AES密钥（eg: crypto.pbkdf2Sync(password, salt, 100000, 32, 'sha512')）。

2 IV（初始化向量）的致命陷阱

禁止： 每次加密固定IV（如"1234567890abcdef"）
后果：相同明文产生相同密文，完全失去语义安全
✅ 必须： 每次加密生成新随机IV，并随密文一起存储（通常放在开始16字节）。
注意： GCM模式IV长度推荐12字节（96位），若短于12字节自动填充，但会降低安全性。

3 填充模式常见死法

死法①：Java默认使用PKCS5Padding（实际是PKCS7），但用CBC时必须指定
✅ 明确写死：AES/CBC/PKCS5Padding
死法②：使用ECB模式以为安全（实际NIST已明确禁用）
✅ 全部转为GCM/CTR模式，除非你明确知道ECB的应用限制（如加密固定格式会话ID）。

4 附加数据（AAD）的威力

GCM模式支持附加认证数据（AAD），即不加密但参与完整性校验的字段。
最佳实践： 将用户ID、时间戳等明文元数据作为AAD，防止密文被篡改后换到另一个用户身上。

5️⃣ 【安全问答】常见误区与行业最佳实践

Q：是不是只要用了AES，数据就100%安全？
A：不是，AES只解决“传输/存储”环节的机密性，但端点安全（密钥被木马窃取）、侧信道攻击（功耗分析）、密钥泄露（同事离职未轮换）才是更大威胁，安全体系=加密+密钥管理+访问控制+审计日志。

Q：为什么有些教程推荐AES+Base64？
A：因为密文是二进制数据，Base64编码后便于文本传输（JSON/XML/URL），但注意：加密必须在编码之前，错误顺序：先Base64再加密，会破坏结构。

Q：我的数据库已经SSL加密了，还需要AES加密字段吗？
A：需要，SSL仅保护传输过程，数据库管理员（DBA）可以直查字段明文，字段级加密（AES-GCM）确保即使数据库泄露，黑客也无法读取敏感字段（如身份证、手机号）。

Q：AES加密后，为什么密文变长了？
A：常见原因：

GCM模式：密文长度=明文长度 + 16字节tag；
CBC模式：因PKCS7填充，密文长度向上取整到16的倍数；
加上IV（12-16字节），总长度比明文多约30-50%。

🛡️ 总结与行动清单

步骤	必须做	禁止做
选算法	AES-256-GCM	使用ECB模式
生成密钥	随机字节（32字节）	硬编码密钥
处理IV	每次加密新随机IV	固定IV
存储数据	保存 iv+密文+tag	只存密文
用户密码	用bcrypt/KDF导出密钥	直接当密钥

最后再强调一次： 技术选型不要自己去“卷”算法。在2025年，直接用你编程语言标准库的AES-GCM实现（比如Node.js的createCipheriv('aes-256-gcm')），永远比你自己拼凑CBC+HMAC安全。