AES 在线加密解密

在线对文本做加密和解密，支持 AES、TripleDES、Rabbit、RC4 等算法，可自定义密钥，全部在浏览器本地计算，密钥不会上传服务器

AES 在线加密解密是什么

在线做 AES 对称加解密。可配置链路支持密钥长度（128 / 192 / 256 位）、分组模式（CBC / ECB / CTR / OFB / CFB）、填充方式（PKCS#7 / Zero / ISO10126 / Ansix923 / 不填充）、真实的 16 字节 IV，以及明文与密文两侧的字符集（UTF-8 / GBK / UTF-16LE / Base64 / Hex）；密钥和 IV 都可以用 [HEX]: 前缀直接粘十六进制原始字节。另有 TripleDES、RC4、Rabbit、Salsa20、ChaCha20、AES-GCM/SIV/KW 等历史算法，保留原有实现以便解开旧密文。验证一段密文、调试接口加密、临时保护一段配置时用，全程在浏览器本地完成。

所有计算都在你的浏览器本地完成，输入的内容不会上传到服务器。

怎么用AES 在线加密解密

在「算法与参数」里选算法：默认是「AES（可配置）」，也可以切到下面那些历史算法
可配置模式下依次选密钥长度、分组模式、填充方式。CBC / CTR / OFB / CFB 需要 16 字节 IV，ECB 不需要
填密钥：128 位要 16 字节、192 位要 24 字节、256 位要 32 字节。手里是 32 位十六进制就写 [HEX]: 开头直接粘，比在编码下拉里切换不容易错
选明文编码与密文表示：中文文本用 UTF-8，从老系统复制来的报文可能是 GBK，密文建议 Base64 或 Hex
在「加密」里输入明文，密文实时出现在下方；点「拿去解密」把结果带过去可以立刻反向验证
解密时把密文贴进「解密」，密钥、位数、模式、填充、IV 五项必须与加密方完全一致

示例

输入

NIST SP 800-38A 的 AES-128-CBC 官方向量：密钥 [HEX]:2b7e151628aed2a6abf7158809cf4f3c，IV [HEX]:000102030405060708090a0b0c0d0e0f，位数 128 bit，模式 CBC，填充「不填充」，明文编码 Hex 并填入 6bc1bee22e409f96e93d7e117393172a

输出

7649abac8119b246cee98e9b12e9197d（密文表示选 Hex）

这段密文可以直接拿去和 OpenSSL、Java、Python 的实现对照：openssl enc -aes-128-cbc -nopad -K 2b7e... -iv 0001... 的输出与它逐字节一致。

常见问题

解密提示「填充校验不通过」是什么意思？

这几乎都意味着参数不匹配：密钥不对、IV 不对、模式选错（对方是 CBC 而你选了 ECB），或者填充方式与加密方不一致。分组密码解密本身不会校验口令，只有当解出来的末尾字节不符合填充规则时才会被判定失败，所以它其实是「参数对不上」的信号，而不是「密文坏了」。

能解密 Java / openssl / 前端库生成的 AES 密文吗？

可以，前提是五项参数对齐：密钥长度、模式、填充、IV、字符集。Java 的 Cipher.getInstance(AES/CBC/PKCS5Padding) 用的是 PKCS#5/7 填充，Node 的 createCipheriv 默认也是 PKCS#7；这两者都能用「AES（可配置）+ CBC + PKCS#7」解开。密文如果是 Base64，把输出格式选 Base64；如果是十六进制就选 Hex。

「[HEX]: 前缀」是干什么的？

它声明「后面这串是原始字节的十六进制表示」，与字符集下拉框无关。比如 [HEX]:2b7e151628aed2a6abf7158809cf4f3c 就是 16 个字节，不会被当成 32 个字符的文本。前缀后面只允许十六进制与空白，出现别的字符会直接报错并指出是哪个 —— 否则密钥录错了照样能加密，只是对方永远解不开。

为什么有两种 AES（可配置 / 历史算法）？

历史算法是原有实现，它们把「自动生成随机 nonce 并前置到密文」写进了算法名里（AES-GCM、AES-CTR 都是），如果改成显式 IV，以前所有密文都会解不开。所以这里并存两条链路：要精确控制参数就用可配置那条，要解旧密文就切到历史算法对应的名字。

密钥用中文可以吗？

可以，但要先按你选的编码变成字节：一个汉字在 UTF-8 里占 3 字节、在 GBK 里占 2 字节。所以「8 个汉字」在 GBK 下正好 16 字节（AES-128 刚好），在 UTF-8 下是 24 字节（AES-192 刚好，选 128 位就会被截断）。跨系统对接用十六进制密钥最不容易出岔子。

密钥和明文会上传吗？

不会。AES 计算全部在你的浏览器里跑，没有任何网络请求，密钥也不会写进 localStorage，关掉页面就什么都不剩。

小提示

位数与密钥长度必须匹配。密钥不足会在末尾补 0x00、超出会截断，两种情况的确切字节数都写在输入框下面 —— 这个提示不能忽略，因为「能加密但对方解不开」几乎都是密钥被悄悄补齐或截断了
CTR / OFB / CFB 是流模式，不需要填充，密文长度与明文相同；ECB / CBC 是分组模式，密文必然是 16 字节的整数倍
ECB 不隐藏相同明文块的规律：同样的 16 字节明文块会得到同样的密文块，正式系统里优先选 CBC 或 AEAD 模式
Zero 填充是有损的：解密只能把末尾的 0 都去掉，如果明文末尾本来就是 0 字节，那部分会丢。需要精确还原就用 PKCS#7
历史算法那一档保持原有实现不变（UTF-8 文本进、Base64 出，AES-GCM 等会把随机 nonce 拼在密文前面），选它们主要是为了解开以前生成的密文
IV 不需要保密，但同一个密钥下不能重复使用同一个 IV —— CBC 的 IV 重复会泄露明文块的相同性，CTR/OFB/CFB 的 IV 重复会直接泄露明文

AES 在线加密解密