AES 加密算法完整指南

AES (Advanced Encryption Standard) 即高级加密标准，由两位比利时密码学家 Joan Daemen 和 Vincent Rijmen 设计，最初名为 Rijndael。2001 年，美国国家标准与技术研究院（NIST）经过 5 年的公开竞赛和评估，正式将其发布为联邦信息处理标准 FIPS 197，取代了已使用多年的 DES（数据加密标准）。

AES 之所以被称为"分组对称加密"，包含两层关键含义：

• 分组（Block）：AES 每次处理固定长度的 128 位（16 字节）数据块。如果明文长度不是 16 的整数倍，则需要填充。
• 对称（Symmetric）：加密和解密使用同一把密钥。这意味着通信双方必须在安全通道下共享密钥，但运算速度极快，适合批量数据加密。

AES 支持三种标准密钥长度：128 位（16 字节，10 轮迭代）、192 位（24 字节，12 轮迭代）、256 位（32 字节，14 轮迭代）。更长的密钥提供更高的安全性，但会略微增加运算开销。

在实际部署中，AES 已成为全球事实上的加密标准。它被广泛用于 TLS 1.3 / HTTPS 网站加密、WPA2 / WPA3 无线网络、BitLocker / FileVault 磁盘加密、VPN 隧道加密、数据库敏感字段保护、移动应用数据加密、电子商务支付系统、智能卡与硬件安全模块等几乎所有需要数据保密的场景。它的安全性经受了全球密码学界 20 多年的公开审查，目前仍被认为是安全的。

我们的在线 AES 工具保留了该算法的实用价值，同时为开发者提供一站式的在线加密解密与结果复制。

AES 的核心运算可以用一句话概括：将 128 位明文输入经过多轮变换，最终产生 128 位密文。理解这个过程对正确使用 AES 至关重要。

AES 采用 SP 网络结构（Substitution-Permutation Network，代换-置换网络），每一轮由四个步骤组成：

• 字节代换（SubBytes）：通过一个固定的 16×16 S 盒查表将每个字节映射为另一个字节，提供混淆（Confusion）能力，使密钥和密文之间的关系复杂化。
• 行移位（ShiftRows）：将 4×4 状态矩阵的每一行按不同的偏移量进行循环移位（第 0 行不移位，第 1 行左移 1 字节，第 2 行左移 2 字节，第 3 行左移 3 字节），提供扩散能力。
• 列混合（MixColumns）：将状态矩阵的每一列与一个固定多项式在 GF(2^8) 有限域上进行矩阵乘法，使一列中的 4 个字节相互混合，提供扩散（Diffusion）能力，确保单个明文位的变化能影响多个密文位。
• 轮密钥加（AddRoundKey）：将状态矩阵的每一字节与从主密钥扩展出来的轮密钥进行逐位异或（XOR）。

密钥扩展（Key Expansion）是 AES 的另一个重要组成部分：主密钥通过特定算法扩展出一系列轮密钥。对于 AES-128，需要扩展出 11 个轮密钥（初始轮 1 个 + 10 轮各 1 个），每个轮密钥为 128 位。扩展过程中使用与 SubBytes 相同的 S 盒，并加入 Rcon（轮常数） 以确保每一轮的轮密钥不同。

完整的加密流程为：

• 初始轮：仅执行 AddRoundKey（与第 0 个轮密钥异或）。
• 第 1~9 轮（以 AES-128 为例）：依次执行 SubBytes → ShiftRows → MixColumns → AddRoundKey。
• 第 10 轮（最后一轮）：执行 SubBytes → ShiftRows → AddRoundKey（无 MixColumns）。

解密过程与加密类似，但步骤顺序和轮密钥顺序相反：逆 S 盒、逆行移位、逆列混合、轮密钥逆序使用。

理解这个结构后，你就能准确回答为什么 AES 的分组长度固定为 128 位、为什么 ECB 模式下相同明文会产生相同密文、为什么 IV 在 CBC 模式中如此重要 等实际问题。

AES 本身只定义了如何加密单个 16 字节分组。当需要加密变长数据时，必须配合工作模式（Mode of Operation）使用。不同的模式在安全性、实现复杂度、并行处理能力、错误传播等方面各有特点。

① ECB（Electronic Codebook，电子密码本）

ECB 是最简单的模式：每个明文分组独立加密。优点是简单、可并行处理、无错误传播。缺点是相同明文产生相同密文，容易泄露数据模式。一个经典的例子是：用 ECB 加密一张含有大面积重复区域的图片，加密后仍能看出原始轮廓。不推荐用于敏感数据。

② CBC（Cipher Block Chaining，密码块链接）

每个明文分组在加密前先与前一个分组的密文进行异或（XOR）。第一个分组需要与一个初始向量（IV）进行异或。CBC 是目前最常用的模式之一，优点是隐藏了明文的模式，相同明文分组会产生不同密文。缺点是加密过程无法并行（但解密可以）、IV 必须是随机的（不可预测）。CBC 模式配合 PKCS7 填充是 Web 开发中最经典的组合。

③ CTR（Counter，计数器模式）

CTR 将 AES 当作流密码来使用，通过加密一个递增的计数器值来产生密钥流（keystream），再与明文逐位异或。优点是无需填充、加解密完全一致、可完全并行处理、随机访问密文。缺点是对计数器重复非常敏感（如果同一密钥下的计数器值重复，将直接泄露明文）。CTR 是 GCM 模式的基础。

④ OFB（Output Feedback，输出反馈模式）

OFB 与 CTR 类似，也是流密码模式，但它通过不断反馈加密输出作为下一次的输入来产生密钥流。优点是无需填充、无错误传播。缺点是无法并行处理、对 IV 与密钥的组合重复敏感。OFB 适合信道质量不稳定的场景（如卫星通信），但在现代系统中已逐渐被 CTR 或 GCM 取代。

⑤ CFB（Cipher Feedback，密码反馈模式）

CFB 将前一个分组的密文反馈作为输入，加密后与当前明文异或产生当前密文。它同样是流密码模式，无需填充。CFB 有多种变体（CFB-8、CFB-64 等），适合按字节或按位处理数据的场景（如网络数据包）。

⑥ GCM（Galois/Counter Mode，伽罗瓦/计数器模式）

GCM 是一种认证加密（Authenticated Encryption）模式，同时提供保密性和完整性认证。它在 CTR 模式的基础上增加了 GHASH（伽罗瓦哈希）运算，用于生成认证标签（Tag）。接收方在解密时同时验证标签，如果标签不匹配则拒绝解密，有效防御密文篡改攻击。GCM 还支持 AAD（Additional Authenticated Data，附加认证数据）——一段不加密但需要保护完整性的数据（如 HTTP 头、协议元数据）。GCM 是目前最推荐的模式，广泛用于 TLS 1.3、IPsec、SSH、无线通信等现代协议。

填充方式（Padding）的选择也很重要。常见的填充方案：

• PKCS7 / PKCS5：最常用，每个缺失字节填充等于缺失字节数的值。例如缺少 3 字节，则填充 0x03 0x03 0x03。
• ZeroPadding：用零字节填充，但无法区分原始数据末尾的零。
• ANSIX923：末尾填字节数，其余位置填零。
• ISO10126：末尾填字节数，其余位置填随机字节。

在流模式（CTR、OFB）和认证模式（GCM）下，通常不需要填充。

我们的工具支持以上所有主流模式，配合多种编码与填充方式切换，方便您在不同场景中快速验证。

AES 作为全球事实上的加密标准，应用场景几乎涵盖了所有需要数据保密的领域。以下是 7 个最典型的真实使用场景：

① HTTPS / TLS 网络传输加密

在浏览器与服务器之间的 HTTPS 通信中，TLS 握手完成后，会话数据通常使用 AES-GCM 或 AES-CBC 进行对称加密。AES 的高性能使其能够轻松处理每秒数百兆甚至数吉字节的网络流量，是 HTTPS 性能的关键保障。

② WPA2 / WPA3 无线局域网加密

家庭和企业 Wi-Fi 的 WPA2 协议基于 AES-CCMP（CTR 模式 + CBC-MAC），WPA3 进一步使用 AES-GCMP。路由器与终端之间的所有数据包在传输前都经过 AES 加密，有效防御无线窃听。

③ BitLocker / FileVault 整盘加密

Windows 的 BitLocker 和 macOS 的 FileVault 使用 AES 在块设备层对整个磁盘进行加密。即使硬盘被盗，攻击者在没有密钥的情况下也无法恢复数据。这是企业终端安全和数据泄露防护（DLP）的基础措施。

④ 数据库敏感字段加密

身份证号、手机号、银行卡号、客户地址、健康记录等敏感字段在写入数据库前用 AES 加密。即使数据库被拖库，攻击者也无法直接读取敏感信息。配合密钥管理系统（KMS）能实现更完善的数据脱敏与合规。

⑤ VPN 隧道加密（IPsec / OpenVPN / WireGuard）

企业远程办公常用的 IPsec VPN、OpenVPN 等协议中，AES 承担会话数据的对称加密任务。WireGuard 协议默认使用 ChaCha20-Poly1305，但在大多数实现中同时支持 AES-GCM。

⑥ 移动应用与 API 接口数据保护

在移动端 App 与后端 API 的通信中，除了 HTTPS 传输层加密，开发者通常会对关键业务数据（如支付令牌、用户凭证）进行额外的应用层 AES 加密。这提供了"深度防御"——即使某一层被突破，另一层仍能保护用户数据。

⑦ 智能卡、硬件安全模块（HSM）与物联网

银行卡、SIM 卡、U 盾、HSM 等硬件设备通常内置了 AES 硬件加速引擎，用于在受限环境中进行高性能加密运算。在物联网（IoT）场景中，轻量级设备也大量使用 AES 保护传感器数据、固件更新与设备通信。

简而言之：只要你需要对数据进行对称加密，AES 就是性能与生态最成熟的首选算法。

在实际应用中，选择合适的密钥长度和工作模式对安全性和性能都有影响。以下是对比与建议：

密钥长度对比

• AES-128：128 位密钥，10 轮迭代。安全强度足以抵御当前所有已知攻击（包括量子计算在短期内的威胁）。美国联邦政府也使用它处理 SECRET 级信息。性能最佳（轮数最少），密钥管理开销最小。
• AES-192：192 位密钥，12 轮迭代。安全强度更高。主要用于需要与特定系统（如某些政府和企业系统）兼容的场景。在普通 Web 开发中较少使用。
• AES-256：256 位密钥，14 轮迭代。提供最高安全级别，可防御量子计算威胁，适用于处理 TOP SECRET 级信息。性能略低于 AES-128（轮数更多），但在现代 CPU 上差异不大。

工作模式对比与推荐

• 需要认证加密（最推荐）：选择 GCM。同时提供加密和完整性认证，防御密文篡改。广泛用于 TLS 1.3、现代 API、移动端。
• 传统文件加密与数据加密：选择 CBC + PKCS7。生态最成熟，兼容性最好。注意 IV 必须是随机的。
• 流密码模式 / 随机访问密文：选择 CTR。无需填充，可并行处理。
• 兼容旧系统：可能需要使用 ECB、OFB、CFB，但在新系统中不推荐。

IV 管理的最佳实践

• CBC 模式：IV 必须是随机且不可预测的（使用密码学安全的随机数生成器，如 crypto.getRandomValues() 或 openssl_random_pseudo_bytes()）。IV 不需要保密，可以与密文一起传输。
• CTR / GCM 模式：IV（在 GCM 中称为 nonce）在同一密钥下必须永不重复。如果 nonce 重复，攻击者可以计算出密钥流并恢复明文。推荐做法：使用 12 字节（96 位）的计数器或随机 nonce。
• ECB 模式：不需要 IV。但正因如此，ECB 不推荐用于敏感数据。

实际选择建议

• 场景涉及新系统、现代协议、对安全性和完整性有高要求 → 选择 AES-128-GCM 或 AES-256-GCM。
• 场景涉及与旧系统兼容、文件加密、传统 API → 选择 AES-128-CBC + PKCS7。
• 不确定时，优先选择 GCM——它同时提供保密性和认证，是当前最安全且最主流的选择。

即使使用 AES 这样的标准算法，错误的用法也可能导致严重的安全漏洞。以下是 5 个实用技巧，帮助您避免常见踩坑：

① 使用密码学安全的随机数生成器

生成密钥和 IV 时，切勿使用普通随机数（如 JavaScript 的 Math.random() 或 Java 的 java.util.Random）。这些生成器的输出是可预测的，攻击者可以复现您的"随机"值。应使用操作系统提供的密码学安全随机数生成器（CSPRNG）：在浏览器中使用 crypto.getRandomValues()，在 Node.js 中使用 crypto.randomBytes()，在 Linux 中读取 /dev/urandom。

② 妥善管理密钥，永远不要在代码中硬编码

密钥是 AES 安全的核心。永远不要在源代码、配置文件、前端 JavaScript 中硬编码密钥。推荐使用：密钥管理系统（KMS，如 AWS KMS、阿里云 KMS、HashiCorp Vault）、硬件安全模块（HSM）、环境变量（仅用于开发环境）、密码学安全的密钥派生函数（KDF，如 Argon2、PBKDF2、scrypt、bcrypt）从用户口令派生密钥。密钥必须定期轮换（rotate），并最小化授权访问（least privilege）。

③ 优先选择带认证的加密模式（AEAD）

如果您的系统支持，优先使用 AES-GCM 而非 AES-CBC。GCM 同时提供保密性（Confidentiality）和完整性认证（Integrity / Authentication），能有效防御密文篡改攻击（如 padding oracle 攻击、字节翻转攻击）。在 CBC 模式下，如果您没有单独的 MAC（消息认证码），攻击者可能通过发送精心构造的密文并观察解密失败信息来逐步恢复明文。

④ 使用标准库和经过审计的实现

不要自己实现 AES（或任何密码学原语）。使用经过广泛审计和测试的标准库：JavaScript 中的 Web Crypto API 或 crypto-js、Java 中的 javax.crypto、Python 中的 cryptography 模块、Go 中的 crypto/aes 包。这些实现已经过数百万开发者的验证。

⑤ 确保加解密双方的参数完全一致

AES 解密失败最常见的原因是：密钥、工作模式、填充方式、IV（偏移量）、编码格式（Hex / Base64 / UTF-8）中有一项或多项不匹配。建议在设计协议或 API 时，显式声明所有加密参数（例如：AES-256-CBC/PKCS7，IV 为 16 字节随机值并前置在密文前，密文输出为 Base64 编码）。建立清晰的文档和单元测试，确保加解密双方的实现完全一致。

🔒 本地浏览器运算：我们的 AES 工具完全在您的浏览器中运行。所有加解密运算均在本地 JavaScript 引擎中完成。您的明文、密文、密钥、IV、AAD、Tag 等信息不会上传到任何服务器，也不会被记录在任何日志中。即使在无网络连接的情况下，工具也能正常运行。

🛡️ 安全使用建议：使用本工具处理敏感数据时，建议在关闭浏览器扩展/插件的隐私模式下操作，并确保您的设备未被植入恶意软件。请勿在公共电脑或不可信设备上处理高度敏感信息。处理完毕后，请及时清除浏览器缓存，并关闭页面。

⚡ 高性能运算：AES 算法设计得极为高效，在现代 CPU 上通常有专用的 AES-NI（AES 新指令集）硬件加速。我们的工具使用标准的 JavaScript 实现，在普通笔记本电脑上每秒可处理数十兆字节的数据，完全可以满足日常开发与测试的需求。

🌐 开源与透明：我们使用业界标准的加密实现，算法逻辑对所有用户公开透明，确保没有任何隐藏的行为。数据安全与隐私是我们最核心的承诺。

⚠️ 法律合规提示：请确保您在使用本工具时遵守所在国家和地区的法律法规。本工具仅用于合法的数据保护、开发测试与学习研究用途，严禁用于任何非法目的。

💡 最后提醒：密码学是一门深奥的学科。本文提供的是概念性的介绍与实用建议，不能替代专业的安全审计。在生产系统中部署加密方案时，强烈建议咨询专业密码学家或安全工程师。我们的在线 AES 工具可以作为您日常开发与学习的辅助工具，但生产环境的安全需要系统性的保障。