什么时候使用
适合双方已经安全共享同一密钥或口令，需要加解密文本的场景。新数据优先使用默认的 AES-256-GCM；只有在对接方明确要求时，才切换到 CBC、CTR、CFB、ECB 或原始参数。
如果你只有接收方 RSA 公钥并且正文较长，请改用 RSA + AES 混合加解密工具。
快速使用
- 保持默认参数，点击“生成随机密钥”。
- 输入明文并点击“AES-256-GCM 加密”。
- 分别保存生成的密钥和 AES v4 JSON；解密时粘贴 JSON，页面会自动同步其中的算法参数。
工具说明
这个工具可以使用 AES-128、AES-192 或 AES-256 加解密 UTF-8 文本，并支持 GCM、CBC、CTR、CFB、ECB 五种工作模式。页面默认使用 AES-256 + GCM + NoPadding。
当前页面同时提供：
- Base64 原始密钥和 PBKDF2-HMAC-SHA-256 口令派生两种密钥来源。
- 自描述的 AES v4 JSON，以及拆分密文、IV、认证标签和盐值的原始参数模式。
- 仅适用于 GCM 的 UTF-8 或标准 Base64 AAD。
- 浏览器随机生成密钥、口令、盐、IV 或计数器。
所有密钥、口令、明文和密文只在当前浏览器中处理，不会上传或保存。AES 运算由 @noble/ciphers 完成，口令派生使用浏览器 Web Crypto。
密钥长度和来源
Base64 原始密钥
原始密钥长度必须和页面选择一致：
| 密钥长度 | 原始字节数 |
|---|---|
| AES-128 | 16 字节 |
| AES-192 | 24 字节 |
| AES-256 | 32 字节 |
可以粘贴标准 Base64 密钥，也可以在浏览器中生成随机密钥。
PBKDF2 口令派生
口令模式使用 PBKDF2-HMAC-SHA-256、600000 次迭代和每次随机生成的 16 字节盐，派生出当前选择长度的 AES 密钥。JSON 会保存盐和派生参数，但不会保存口令。
工作模式和填充
| 工作模式 | IV 或计数器 | 可用填充 | 完整性认证 |
|---|---|---|---|
| GCM | 随机 12 字节 | NoPadding | 有，128 位认证标签 |
| CBC | 随机 16 字节 | PKCS7、ZeroPadding、NoPadding | 无 |
| CTR | 随机 16 字节 | NoPadding | 无 |
| CFB | 随机 16 字节 | NoPadding | 无，使用 CFB-128 |
| ECB | 无 | PKCS7、ZeroPadding、NoPadding | 无 |
优先使用 GCM。CBC、CTR、CFB 和 ECB 都不能检测密文是否被恶意修改；ECB 还会泄露重复明文块的模式，只应为旧系统兼容或测试而使用。
页面会在每次加密时为 GCM、CBC、CTR、CFB 生成新的随机 IV 或计数器。v4 JSON 会保存该参数；原始参数模式需要自行与密文一起保存。
填充规则
PKCS7：自动补齐并在解密时校验、移除填充。ZeroPadding：使用00补齐；解密会移除末尾全部00，因此不能无歧义保留原文末尾的空字节。NoPadding：CBC 和 ECB 的 UTF-8 明文字节数必须是 16 的倍数。- GCM、CTR 和 CFB 按工作方式固定为
NoPadding。
密文格式
v4 JSON
加密结果是自描述的紧凑 JSON：
{
"v": 4,
"alg": "AES",
"keyLength": 256,
"mode": "GCM",
"padding": "NoPadding",
"secretMode": "passphrase",
"iv": "...",
"ciphertext": "...",
"authTag": "...",
"aad": "...",
"kdf": "PBKDF2-HMAC-SHA-256",
"iterations": 600000,
"salt": "..."
}
ciphertext不包含 GCM 认证标签，GCM 使用独立的authTag字段。aad保存实际 AAD 字节的标准 Base64；没有 AAD 时省略。- ECB 没有
iv字段。 - Base64 原始密钥模式没有 KDF 和盐字段。
- 解密时，页面会读取 JSON 中的密钥长度、工作模式、填充和密钥来源，并自动同步页面参数。
本次格式为不兼容升级，只接受 v4 JSON，不解密旧版 v1/v2/v3 密文。
原始参数
原始参数模式把密文和参数分开显示，便于与 Java、Node.js、OpenSSL 或其他系统联调：
- 所有模式输出独立的 Base64
ciphertext。 - GCM 输出 12 字节 Base64 IV 和 16 字节 Base64 认证标签。
- CBC、CTR、CFB 输出 16 字节 Base64 IV 或计数器。
- 口令模式额外输出 16 字节 Base64 PBKDF2 盐值。
- GCM 解密时还要输入与加密完全相同的 AAD。
原始参数不携带工作模式、填充、密钥长度或密钥来源，解密时必须手动选择一致参数并保存所有必需字段。
GCM AAD
AAD 不会被加密，但会参与 GCM 认证。页面可以把 AAD 按 UTF-8 文本编码，也可以直接接受标准 Base64 字节。v4 JSON 会把最终 AAD 字节保存为 Base64；原始参数模式需要用户在解密时重新提供完全相同的 AAD。
常见问题
PKCS7 和 Java 的 PKCS5Padding 是否相同？
在 AES 的 16 字节分组下，常见 Java 实现名称 PKCS5Padding 实际使用与 PKCS7 等价的分组填充规则。
为什么 NoPadding 提示长度错误？
CBC 和 ECB 一次处理 16 字节分组。文本按 UTF-8 转换后，字节数必须正好是 16 的倍数。
为什么非 GCM 模式修改密文后有时仍能解密？
CBC、CTR、CFB 和 ECB 不提供认证保护，无法可靠检测篡改。生产场景应优先使用 GCM，或为非认证模式另外设计 MAC。
密钥和内容会上传吗？
不会。随机数生成、密钥派生、加密、解密和复制都在当前浏览器中完成。