AES 分组长度固定为 16 字节，敏感数据超过一个分组怎么办？

AES 只规定了一块多大，却没有替你决定数据该怎样排队。

软考题目问：AES 的固定分组长度为 16 字节，用户个人信息、位置信息等敏感数据超过一个分组时，应如何安全处理？这道题考的不是把字符串硬切成 16 字节，而是分组密码的正确使用方式。

先给出 300 字以内的答法

应采用经验证的分组密码工作模式处理多分组数据，例如 AES-GCM（优先）或 AES-CTR 配合 HMAC。加密时为每条消息生成不可预测且不重复的随机 nonce/IV；明文按模式自动分组，最后一组不足 16 字节由模式处理，不应自行补零后直接拼接。密钥应由安全的密钥管理系统生成、保存和轮换，不能硬编码。解密前先校验认证标签（或 HMAC），校验失败立即丢弃，防止篡改和填充预言机攻击。nonce、认证标签和必要的版本号可与密文一起存储，但不得泄露密钥。ECB 模式会泄露重复块的模式，不能用于此类敏感信息。

为什么不能“每 16 字节单独 AES 一次”

分组密码本身只能处理 16 字节输入。面对更长的个人资料，应用层应交给 GCM、CTR、CBC 等工作模式，由模式定义计数器、链式关系和最后一块的处理规则。把每块用同一个密钥独立加密，效果接近 ECB：相同的明文块会产生相同的密文块，姓名、坐标或 JSON 结构的重复模式可能暴露出来。

CBC 需要随机且不可预测的 IV，并且还要额外配置 HMAC；CTR 不能复用 nonce；GCM 同时提供加密和完整性保护，工程上通常更省心。无论选择哪种模式，都不能复用同一 nonce-key 组合。

一条可落地的数据路径

可以把密文记录设计成：版本号 | 算法标识 | nonce | ciphertext | tag。服务端从密钥管理系统取到密钥后生成 nonce，调用成熟密码库完成加密；读取时先验证 tag，再把明文交给业务逻辑。日志、缓存、异常堆栈也要避免把明文带出去，密钥轮换则通过版本号支持平滑迁移。

这道题真正想提醒的是：16 字节是算法接口的边界，不是业务数据的长度上限。安全性来自正确的模式、唯一的 nonce、可靠的密钥管理和解密前的完整性校验，四件事缺一都可能让“加密了”变成心理安慰。

版权声明: 本文首发于 指尖魔法屋-AES 分组长度固定为 16 字节，敏感数据超过一个分组怎么办？（https://blog.thinkmoon.cn/post/1000-aes-block-size-sensitive-data/） 转载或引用必须申明原指尖魔法屋来源及源地址！