AES加密解密

AES、密钥与分组分别决定什么

一段“Hello世界”先按 UTF-8 变成字节，再由密钥、工作模式、填充方式和初始向量共同决定最终密文。AES 是对称分组密码：加密方与解密方使用同一把秘密密钥，算法每次处理固定的 128 位（16 字节）数据块。AES-128、AES-192、AES-256 中的数字指密钥长度，不是明文或密文长度；在页面中分别对应 16、24、32 字节密钥。

密钥可按“文本”“Hex”或“Base64”解释。文本密钥按 UTF-8 字节计数，因此 16 个汉字通常不等于 16 字节；Hex 每两个十六进制字符表示 1 字节，例如 AES-128 需要 32 个合法 Hex 字符；Base64 则先解码，再检查得到的字节数。页面也可生成与所选 AES 长度匹配的随机 Hex 密钥。

模式、IV 与填充必须成套记录

页面可选 ECB、CBC、CFB、OFB、CTR 五种模式，默认组合是 AES-256、CBC、PKCS7。除 ECB 外，页面都会要求初始向量（IV）；AES 的 IV 字段应表示 16 字节，可选择 Hex 或 Base64，进行加密时也可自动生成。IV 不等于密钥，但解密端必须拿到与加密时完全相同的值。

页面选项	IV	联调时要确认的重点
ECB	不使用	相同明文块会形成相同密文块，不适合一般敏感数据
CBC	必填	IV、填充、密钥与密文编码必须一致
CFB / OFB	必填	双方仍需选择完全相同的模式与参数
CTR	页面以 IV 字段接收	双方需约定相同的初始计数值表示方式

可选填充为 PKCS7、Zero Padding、No Padding、ISO10126 和 ANSI X.923。填充是把数据补到算法所需边界的规则，不是额外加密。No Padding 尤其要求调用方自行保证输入长度满足所选模式的要求；跨语言联调时，不要仅凭“AES-256”四个字判断兼容，还要逐项核对模式与填充。

Base64 与 Hex 只改变密文的写法

加密结果同时给出 Base64 和 Hex，两者是同一组密文字节的两种文本表示，不会改变 AES 强度。解密输入可明确选择 Base64 或 Hex；选错格式、混入前缀或截断字符，都可能得到错误结果。解密成功后，页面显示 UTF-8 文本，并同时给出明文字节的 Base64 与 Hex 表示。

输出是原始密文字节的编码，不会自动把 IV、模式、填充、密钥格式或版本信息封装进密文。若要把结果交给另一个系统，至少应另行传递或约定这些非秘密参数，并安全保存密钥。也不要把其他软件生成的带盐头部、口令派生信息或认证标签的字符串直接当作这里的原始密文。

标准依据与安全结论

从明文得到可复现的密文

1. 确定对接参数

   先从接收方或协议中确认密钥位数、模式、填充、密钥格式、IV 格式和密文格式。若没有既定协议，可从页面默认的 AES-256/CBC/PKCS7 开始做测试，但默认值不等于任何外部系统的约定。

2. 填写或生成密钥

   选择“文本”“Hex”或“Base64”后再输入密钥。页面会按解码后的字节数校验长度；生成按钮产生 Hex 密钥，切换格式并不会自动改写现有字符的含义。

3. 处理 IV

   ECB 不显示 IV 输入；其余模式可保留“自动生成”。加密完成后应立即记录显示出的 IV。若要复现固定测试结果，关闭自动生成，手动填入 16 字节的 Hex 或 Base64 IV。

4. 加密并保存参数

   在“加密”页输入明文，点击“加密”，再按对接要求复制 Base64 或 Hex 密文。密文与密钥应分开保管，同时保存模式、填充、IV、字符编码和密文编码。

5. 切换到解密核验

   选择“解密”后，先选 Base64 或 Hex，再粘贴密文并恢复原来的全部参数。点击“解密”，用文本结果核对内容；若原始明文不是 UTF-8 文本，应以 Hex 或 Base64 字节结果为准。

一组可以复查的 CBC 示例

选择 AES-128、CBC、PKCS7；密钥格式选 Hex，填入 000102030405060708090a0b0c0d0e0f；关闭 IV 自动生成并填入 Hex 值 101112131415161718191a1b1c1d1e1f；明文输入 Hello世界。页面得到的 Hex 密文应为：

14ae6c0841ce63fa59237b03dee17cdd

对应 Base64 为 FK5sCEHOY/pZI3sD3uF83Q==。把该 Base64 放入解密输入，保持所有参数不变，文本结果应回到 Hello世界。若只把 IV 改为 202122232425262728292a2b2c2d2e2f，Hex 密文会变为 ff871222d345aa0c0510a65e3f8c9143；这说明同一密钥和明文在不同 IV 下产生不同密文是正常现象。

参数对不上时先查这四件事

同一明文和密钥，为什么两次密文不同？

若使用 CBC、CFB、OFB 或 CTR 且自动生成 IV，两次 IV 不同就会得到不同密文，这是预期结果。要做跨系统对拍，请暂时固定相同 IV；实际长期使用仍应遵循所选模式对 IV 唯一性或不可预测性的要求。

为什么别处的 AES 结果与这里不同？

先比较原始字节，而不是只看界面文字。重点核对密钥究竟按 UTF-8、Hex 还是 Base64 解释，明文是否为 UTF-8，模式、填充、IV 是否相同，以及对方是否把盐、IV 或认证标签拼进了密文；只要一项不同，结果就不会一致。

解密失败或文本乱码通常是什么原因？

最常见原因是密钥、IV、模式、填充或密文编码不匹配，也可能是密文被截断。另一种情况是原始明文本来就是二进制而非 UTF-8 文本，此时不应强行把字节解释成文字；请回到数据协议确认原始编码。

普通登录密码能直接当 AES 密钥吗？

不能把任意长度口令直接视作合格密钥。这个页面要求解码后恰好为 16、24 或 32 字节，并不会替你从短口令派生密钥；正式系统应使用经过评审的密钥派生与密钥管理方案。若目标是保存用户登录密码，应使用专门的密码哈希方案，而不是可逆 AES 加密。

用于联调前请确认这些边界

页面支持的 ECB、CBC、CFB、OFB、CTR 均不输出认证标签，因此结果主要用于参数学习、测试向量核对和兼容性排查。它不能单独证明密文未被篡改，也不应直接替代经过安全评审的生产加密方案。

• 不要误找 GCM：当前可选列表没有 GCM、CCM、AAD 或认证标签。生产场景需要同时保护机密性和完整性时，应优先选用正式环境中经过审计的带认证加密方案；若协议限定 CBC 或 CTR，完整性保护也必须由协议明确设计。
• 不要复用密钥材料：密钥应随机生成、限制访问、按风险轮换，并与密文分开管理。IV 通常不需要保密，但必须符合所选模式的规则且随密文可靠保存；不要把固定 IV 当作默认生产配置。
• 谨慎处理真实秘密：加解密运算本身在当前浏览器中完成，不依赖外部数据源，但浏览器扩展、剪贴板、共享设备、屏幕记录和恶意页面都可能暴露输入。真实生产密钥、个人信息或商业机密不宜粘贴到非受控环境。
• 以协议字节为准：文本显示只适合 UTF-8 明文。二进制数据、损坏密文或错误参数可能无法显示为文字；跨语言系统还应明确字符编码、Base64 变体、Hex 大小写容忍度以及参数封装顺序。