AES 在线加密实战：正确处理 Key、IV、模式和输出编码

在线 AES 工具最适合做两件事：生成可控的测试密文，以及帮助你理解某套加密配置为什么能或不能被另一端解开。它不适合拿来临时处理生产 secret、客户资料或长期凭据。真正要关注的也不是“点加密按钮”，而是 key、IV、mode、padding 和输出编码是否被完整记录。

AES Encrypt 可以用于浏览器里的加密/解密验证。建议先用假数据跑通，再把相同配方写进代码或联调文档。

先定义你要解决的场景

同样是 AES 加密，场景不同，配置选择也不同。

如果你是在和后端联调，目标通常是复现对方文档里的密文格式：例如 AES-256-CBC、PKCS7、IV 单独传、密文 Base64。如果你是在写测试 fixture，目标是让未来的人能用同一组参数稳定解密。如果你是在保护真实用户数据，在线工具通常不应该进入生产流程，而应使用后端密钥管理和经过审查的加密库。

所以开始前先写下三件事：谁会解密、解密方期待什么格式、这段数据是否敏感。答案不清楚时，不要急着生成“看起来随机”的密文。

Key：不要只写“密码是 xxx”

AES 的 key 是字节。AES-128、AES-192、AES-256 分别对应 16、24、32 字节 key。很多误解来自把“人类输入的密码”和“算法使用的 key”混在一起。

例如你输入：

my-demo-secret-for-aes-256-test

它可能被工具当作 UTF-8 字符串，也可能被当作 passphrase 进一步派生。另一端如果期待的是 32 字节 hex key，你直接复制这串文本就不会兼容。更稳妥的联调写法是明确标注：

key format: UTF-8 text
key value: test_key_1234567890123456789012
mode: CBC
padding: PKCS7
iv format: hex
ciphertext format: Base64

如果 key 来自 hex 或 Base64，先确认长度转换后的字节数，而不是只看字符数。必要时用 Base64 Encoder 检查表示层，但不要把 Base64 误认为加密。

IV：它不是第二个密码

IV 的作用是让同样明文在某些模式下不会总是生成相同密文。CBC、CFB、OFB、CTR 等模式通常需要 IV 或 nonce；ECB 不使用 IV。IV 一般不需要保密，但必须在解密时可用。

常见事故是加密时随机生成 IV，却只把密文发给对方；或者解密方为了填字段自己编一个 IV。这样即使 key 正确也解不开。联调时要约定 IV 怎么传：放在密文前 16 字节、单独字段、header，还是由协议固定提供。

如果只是生成测试样例，可以固定一个非敏感 IV，方便双方复现；如果进入生产设计，应使用随机且不重复的 IV，并确保它和密文一起保存。

Mode 和 Padding：按文档匹配，不按感觉选择

CBC + PKCS7 是很多工具的常见组合，但它不是万能默认值。CTR 更像流模式，通常不需要传统 padding；GCM 还涉及认证 tag；ECB 不建议用于新的安全设计。工具里能选，不代表所有选项都适合你的系统。

如果对接方已经给出算法名，照文档填，不要擅自替换。AES-256-CBC、AES/CBC/PKCS5Padding、aes-256-ctr 这些名字背后包含不同约束。尤其是 Java 里的 PKCS5Padding 在 AES 场景下常和 PKCS7 兼容命名混用，但仍要以双方库的实际行为为准。

加密后马上做一次解密回测。如果同一工具、同一配置都不能还原，说明参数还没填对；如果本地能还原但服务端不能，就把差异集中在 key 格式、IV 传递、padding 和输出编码上。

输出编码：Base64 和 hex 只是包装

AES 输出的是二进制字节。为了放进 JSON、表单、日志或数据库，工具会把它显示成 Base64 或 hex。它们不改变加密强度，只影响传输和复制。

选择标准很简单：下游要什么，你就输出什么。API 字段写着 Base64，就不要发 hex；数据库列存 hex，就不要直接塞 Base64。遇到 + 在 URL query 里变空格、末尾 = 被省略、换行被插入这类问题时，优先检查编码传输边界，而不是改 AES 参数。

Hash、Base64 和 AES 不要混用概念

AES 是可逆加密；hash 是单向摘要；Base64 是可逆编码。三者在日志里都可能表现为“看不懂的字符串”，但用途完全不同。需要文件指纹、去重或摘要时，用 Hash Generator。需要后续可解密的密文，才使用 AES。需要把字节安全地放进文本字段，才选择 Base64 或 hex 表示。

一个典型错误是先 AES 加密，再说“我把结果 hash 一下提高安全性”，结果解密方再也拿不到原始密文。除非协议明确要求，不要随意叠加步骤。

推荐联调流程

1. 准备假明文，例如 {"userId":"test_123","role":"demo"}。
2. 明确 key 格式、IV 格式、mode、padding 和输出编码。
3. 在 AES 工具里加密，保存密文和全部参数。
4. 用同一组参数立即解密，确认 round-trip 成功。
5. 把样例交给另一端解密；失败时只改一个变量。
6. 样例稳定后，再把配置迁移到代码和安全流程。
7. 真实数据只在被批准的环境中处理，并避免出现在截图、工单和聊天记录里。

FAQ

为什么同样明文每次加密结果不同？

如果使用随机 IV，这是正常现象。只要解密方拿到相同 IV、key 和参数，就能还原明文。不要为了让密文固定而在生产里复用不该复用的 IV。

AES 加密后的 Base64 可以直接发给 API 吗？

只有 API 文档要求该字段是 Base64 密文时才可以。还要确认 IV、tag、salt 等附加信息是否需要一起发送。

在线工具生成的密文能用于生产吗？

一般不建议。在线工具适合教学、测试和联调样例；生产加密应放在受控代码、密钥管理和审计流程中。