对称加密基础：AES算法原理、密钥长度、模式（ECB/CBC/GCM）

搞REST接口加解密，逃不开AES。我这些年做安全改造，90%的项目最终都落到了AES上。它就像加密界的钢筋混凝土——不是最花哨的，但最可靠。今天我们来拆解一下它的核心细节。

一个微型化但完整的AES加密流程（128-bit）

咱们先不看里的公式，用最直观的图来理解AES在做什么。下面这张图展示了一轮典型加密的完整步骤。我特别在项目调试时把这张图贴在白板上，因为只要漏掉其中任何一步，解密就直接崩掉。

AES单轮加密流程（128-bit密钥） AES-128 单轮加密结构 (不含初始/末轮) 明文 128-bit AddRoundKey (与轮密钥⊕) SubBytes (S-Box替换) ShiftRows (矩阵行循环) MixColumns (列混合运算) 密钥扩展 KeyExpansion 每轮从原始密钥派生出不同轮密钥 轮数 = 10/12/14 取决于128/192/256密钥 注：最后一轮不执行 MixColumns；首轮只有 AddRoundKey

上面这张图是标准一轮加密的结构。128-bit密钥对应10轮，192-bit对应12轮，256-bit对应14轮。每一轮都包含四个核心操作：轮密钥加、字节代换、行移位、列混合。说白了就是不断把明文打散、扩散、再与密钥混合。最后一轮会去掉列混合——我第一次实现时忘了这个区别，解密出来的全是乱码。

密钥长度：128 / 192 / 256

选择密钥长度其实就是权衡安全性和性能。我举个例子：128-bit密钥的暴力破解需要尝试2^128种组合，以目前超算的速度，破解一个128-bit AES需要比宇宙年龄还要长的时间。所以大多数应用场景下128-bit完全够用。

密钥长度轮数安全性评级我的推荐场景
128-bit10极高（对通用攻击免疫）REST API、Web应用、移动端
192-bit12更高（满足最高机密标准）金融、政务系统
256-bit14最高（AES-256已通过NSA批准用于Top Secret）军工、长期存储、高合规场景

避坑指南：别一味追求256-bit。我在一个IoT项目里用过AES-256，结果芯片算力不够导致单次加解密超过200ms，接口直接超时。客户要求的是可用性，不是军工级安全性。先评估业务威胁模型再选密钥长度。

ECB模式：你最好别在生产环境用

ECB（电子密码本模式）是最简单的分组模式——把明文分成128-bit的块，每块用相同密钥独立加密。听起来很直觉对吧？但问题就出在“独立”上。相同明文块会得到相同密文块，这会让加密后的数据暴露出原始数据的模式特征。

我曾经帮一个团队排查过“加密图片后还能看到轮廓”的奇怪现象——他们用的就是ECB模式。图片里大块相同颜色的区域在加密后还是大块相同密文，人物轮廓一清二楚。这哪是加密？简直是给黑客送线索。

警告：除非是测试或历史遗留系统，否则不要在新项目中使用ECB模式。它不提供语义安全（same plaintext → same ciphertext），而且对重放攻击毫无抵抗力。

CBC模式：经典但有过时之嫌

CBC（密码块链接）模式用前一个密文块与当前明文块异或后再加密，引入了“链接”关系。因为第一个块没有前驱，所以需要初始向量IV。IV随机生成且每次加密不同，相同明文就会得到不同密文——这才是我们要的加密效果。

但CBC有个致命弱点：它本质上是串行运算，每个块必须等前一个块加密完才能继续，在并行计算上天然残疾。更头疼的是填充问题——明文不一定是128-bit的整数倍，得用PKCS#7填充。解密时如果填充校验失败，程序可能抛异常；而攻击者可以利用这个异常进行填充预言攻击。

我在项目里遇到的经典案例：一个支付接口用CBC加密，我们开发时自测正常，上线后偶尔出现解密失败。查了三天发现是网关对填充校验过于严格，多了一个字节的填充数据就报错。最后结论：换GCM模式，省掉所有填充烦恼。

GCM模式：现代REST接口的默认选择

GCM（Galois/Counter Mode）结合了CTR模式的加密方式（可并行、无填充）和Galois域上的认证标签，同时提供加密和完整性校验。一个函数同时搞定机密性、真实性和完整性——这就是为什么我强烈推荐它做接口加解密。

GCM工作流程非常优雅：一个随机Nonce（96-bit推荐）与计数器组合生成密钥流，与明文异或得到密文；同时附加认证数据（AAD，比如HTTP头部的部分字段）参与Galois乘法，最终输出一个128-bit的认证标签。接收方可以用同样的Nonce和AAD重新计算标签，如果不一致就直接拒绝，连解密过程都不执行。

特性ECBCBCGCM
安全性低（模式攻击）中（填充预言攻击）高（认证加密）
并行性支持（块独立）不支持（串行）支持（CTR可并行）
填充需求需要需要不需要
完整性验证无无有（GMAC标签）
推荐应用❌ 不推荐过渡方案❤️ REST API首选

实践经验：用GCM时有一个容易被忽略的细节——Nonce不能重复使用。同一个密钥下，哪怕只重复一次Nonce，攻击者就能通过密文异或同时破解两个明文。我团队有个同事半夜上线忘了重置随机数种子，导致连续两次请求生成了相同Nonce，幸亏测试环境及时发现，不然就出大事了。

一个简单的Python GCM加解密示例

说了这么多理论，最后来个能直接跑的代码。我习惯用pycryptodome库，比标准库cryptography更直观。

from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes

# 加密函数
def encrypt_aes_gcm(plaintext: bytes, key: bytes) -> dict:
    cipher = AES.new(key, AES.MODE_GCM)
    ciphertext, tag = cipher.encrypt_and_digest(plaintext)
    # 返回Nonce、密文、认证标签（都是bytes）
    return {
        'nonce': cipher.nonce,
        'ciphertext': ciphertext,
        'tag': tag
    }

# 解密函数
def decrypt_aes_gcm(nonce: bytes, ciphertext: bytes, tag: bytes, key: bytes) -> bytes:
    cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
    try:
        plaintext = cipher.decrypt_and_verify(ciphertext, tag)
        return plaintext
    except (ValueError, KeyError):
        # 标签校验失败说明数据被篡改，此处应记日志并拒绝
        print("数据完整性验证失败！")
        raise

# 使用示例
if __name__ == '__main__':
    key = get_random_bytes(32)  # AES-256
    message = b"Hello, REST API!"
    result = encrypt_aes_gcm(message, key)
    print("密文:", result['ciphertext'].hex())
    
    recovered = decrypt_aes_gcm(
        result['nonce'],
        result['ciphertext'],
        result['tag'],
        key
    )
    print("解密结果:", recovered.decode())

重要提醒：

  • 永远不要硬编码密钥。生产环境建议从KMS、密钥管理服务或环境变量注入。
  • Nonce长度为12字节（96-bit）是GCM的最优选择，别用其他长度引入性能损耗。
  • 把Nonce和Tag拼接到密文前面一起传输，推荐格式：nonce || ciphertext || tag。

对REST接口来说，AES-GCM几乎就是最优解——一次加密同时拿到密文和认证标签，不需要额外计算MAC，也不需要为填充头疼。后面几章我们会把这个集成到Flask/FastAPI等框架里，到时候你就会发现，选对了模式，代码都会少写一半。

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