AES 加密从零讲起

一句话概括：AES 是全球标准的分组密码 — 在 128、192 或 256 位密钥下打乱 16 字节的分组 — 而你选择运行它的模式（GCM、CBC、CTR、ECB）决定了这些分组如何链接、IV 有什么用、以及篡改能否被察觉；除非有特殊理由，请直接选 GCM。

AES 本身是什么（FIPS 197）

分组密码。AES（Rijndael 设计，2001 年由 NIST 标准化为 FIPS 197）每次恰好加密 16 字节。密钥长度 — 16、24 或 32 字节 — 决定了是 AES-128、-192 还是 -256，以及内部轮数（10、12、14 轮）。每一轮通过替换表、行移位和列混合，把分组与由你的密钥派生的轮密钥混合。现实中不存在攻破算法本身的实用攻击：真实世界的失败几乎总是模式、IV 或密钥管理的失误 — 这正是本页余下部分要讲的内容。

为什么需要模式？因为消息很少恰好是 16 字节。模式负责把一次次分组加密粘合起来：ECB 只是独立地加密每个分组；CBC 把每个分组与上一段密文异或；CTR 像流密码一样加密一个计数器再与数据异或；GCM 在 CTR 之上增加了认证标签。AES 本身不变 — 模式决定了你能得到什么样的安全保证。

密钥与密码。AES 密钥是 16、24 或 32 个随机字节。人类密码做不到这一点：本页的“密码”选项用 PBKDF2-HMAC-SHA256 派生出真正的密钥（默认 600,000 次迭代，即 OWASP 2023 基线 — KDF 细节见 HMAC 生成器）。永远不要把密码字符串直接当 AES 密钥用：其熵值只相当于其长度的一小部分。

四种模式对比

模式	IV / nonce	完整性	说明
GCM	12 字节，每条消息唯一	有 — 96..128 位标签	AEAD：各处的推荐默认（TLS 1.3、SSH、文件格式）。还支持 AAD。
CBC	16 字节，不可预测	无	PKCS#7 填充；经典但需要搭配 MAC。填充预言机漏洞是 CBC 的经典陷阱。
CTR	16 字节初始计数器	无	无填充、类似流密码、支持随机访问；同一密钥下重用 nonce 会泄露明文异或明文。
ECB	无	无	相同分组 → 相同密文。即“ECB 企鹅”演示。仅用于兼容。

IV 规则一段话讲完。IV 不是秘密 — 把它随密文一起发送即可 — 但它的唯一性要求各不相同：CBC 要求 IV 不可预测；GCM 和 CTR 只要求同一密钥下绝不重用同一 nonce（GCM 重用更糟：会泄露认证密钥）。本页的“随机 IV”按钮使用浏览器的安全随机数发生器；“全零”按钮是为了复现测试向量，不是给真实消息用的。

填充。CBC 和 ECB 需要完整的分组，因此 PKCS#7 填充会追加 1..16 个字节，每个都等于填充长度。这就是 CBC 密文最多会增长 16 字节的原因，也是用错误密钥解密通常报填充错误的原因。CTR 和 GCM 类似流密码、无需填充 — 密文长度与明文长度完全相等（试试 CTR 模式下的“示例”：43 字节进，43 字节出）。

CFB 和 OFB（剩下的两种经典模式）本页未实现：它们像 CTR 一样是流式的，却没有任何优于 CTR 的地方，主要残存于老协议中。

GCM 增加了什么（AEAD、标签、AAD）

认证加密。GCM = CTR 加密 + 对密文、IV 和 AAD 计算 GHASH 认证器。输出的标签是一切的指纹：密文、IV 或 AAD 哪怕变了一个比特，标签就对不上了，因此接收方可以证明消息完整且来自持有密钥的人。CBC+HMAC 只有在组合方式正确时（先加密后 MAC）才能达到同样效果 — 而 GCM 天生就做对了。

AAD。附加认证数据以明文形式传输，但被标签覆盖：协议头、文件名、算法标识符。接收方必须提供完全一致的 AAD 字节，否则标签校验失败 — 这正是其意义所在。

标签长度。默认的 128 位标签是推荐值；更短的标签（96..120 位）用抗伪造能力换体积。低于 96 位时 GCM 的安全性证明迅速退化，所以本页到此为止。

nonce 灾难。同一密钥下重用 12 字节的 GCM nonce，会泄露两条消息明文的异或以及认证子密钥 — 此后该密钥下所有未来消息都可被伪造。无法保证唯一性的系统应使用抗 nonce 误用变体（AES-GCM-SIV，RFC 8452）。

基准向量 — 在本页复现它们

第一行是著名的 FIPS 197 单分组示例；其余由独立的原生实现（Node.js 调用 OpenSSL）生成，并已在本页引擎上复核。把密钥、IV 和输入粘贴到页面中即可复现每一行。

用例	输入	预期输出
AES-128 单分组（FIPS 197 风格）	key `000102..0f`, plaintext `00112233..ff`	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key `000102..0f`, IV `606162..6b`, plaintext `0011..ef` ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM，同上但加 AAD `deadbeef`	key `000102..1f`	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key `000102..1f`, IV `101112..1f`, plaintext `0011..ef` ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR（输入同上 CBC）	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

常见错误

因为 ECB 不需要 IV 而用它。方便正是陷阱：分组模式直接泄露进密文（加密一张位图，图片依然可见）。ECB 只对单分组或恰好 16 字节的随机密钥可接受 — 实践中永远不该主动选择它。
重用 nonce/IV。在 GCM 或 CTR 的同一密钥下，这是唯一一个能让一切同时崩坏的错误。基于计数器的系统（本页的“随机 IV”按钮）就是为了杜绝这种可能而存在的。
把 IV 当秘密。它不是。把它与密文一起存储或传输。藏起来毫无收益，反而诱使重用。
把密码直接当密钥。"hunter2hunter2hunter2hunter2" 是 32 字节，但不是 256 位熵 — 它只是一个加了填充的词典单词。请用 PBKDF2 派生（本页内置），或生成随机密钥。
以为 CBC 能发现篡改。翻转 CBC 密文中的一个比特，解密会“成功”地得到被悄悄破坏的明文。只有 GCM 的标签（或显式的 HMAC）能让篡改现形。
比较两段 GCM 密文是否相等。随机 nonce 下，同一段明文每次加密的结果都不同 — 这是特性不是缺陷。确定性加密是另一种专用工具。

常见问题

AES-128 还安全吗，还是必须用 256？面对现实的攻击者两者都安全；已知最好的攻击也只削掉安全余量的很小一角。AES-256 主要用于长期机密和抗量子的安心（Grover 算法把密钥强度减半，AES-256 相当于约 128 位）。

为什么 openssl enc 不支持 GCM？enc 命令早于 AEAD 出现，没有地方携带标签；OpenSSL 3.3 为此新增了专门的 aesgcm 命令。本页的 GCM 输出把标签单独放在一行，方便你明确地搬运两者。

什么是密钥包裹（AES-KW）？一种专门用来加密其他密钥的模式，以固定 64 位块处理并自带完整性校验。本页不提供它，因为它的输入输出都是“密钥形状”而非“消息形状” — 误用才是常态。

为什么我的 CTR 密文和明文一样长，CBC 却更长？CTR 和 GCM 是流式的（无填充）；CBC/ECB 用 PKCS#7 填充到完整的 16 字节分组。长度差异是设计使然，不是缺陷。

能解密在别处加密的数据吗？可以，只要你知道确切的模式、密钥、IV（GCM 还需要标签）。本页的输出行精确记录了所有参数，便于在工具之间移植 — 上方的 OpenSSL 框给出了对应的命令行。

AES 加密 / 解密