AES 加解密
CBC/GCM/CTR 模式，口令可 PBKDF2 派生，密文 Hex 或 Base64。
本工具只用浏览器原生 WebCrypto 的真实能力做 AES 加解密，提供 GCM、CBC、CTR 三种模式，密钥可以是 128/192/256 位；密钥要么直接给原始密钥，要么给口令并由 PBKDF2-HMAC-SHA-256 派生。加密结果默认是「KCES 自带头」封装，把模式、密钥来源、迭代次数、盐与 IV 都记在头部，所以「解密」只需贴回同一段内容即可；若要与其他工具对拍，请切到「裸密文（手工 IV/盐）」。
三种模式是流式/分组填充的差异，算法本身都由浏览器实现，本站不掺任何自写的轮转代码。裸密文模式下输出只有密文，IV 与盐自己填、也自己记，本次用到的值只会显示在提示里；界面上被标灰并写明「不生效」的那几项，是当前模式下读不到的。所有计算都在本页完成，不发任何请求。
AES 加解密怎么用
- 填密钥：密钥有两种来源：直接给原始密钥（Hex 或 Base64，必须正好 16、24、32 字节），或者给口令并由 PBKDF2-HMAC-SHA-256 派生（盐 16 字节，迭代次数可填，默认 150000）。
- 三种模式的差别：GCM 是认证加密：密文尾部自动附 16 字节认证标签，密钥或 IV 稍错就会明确报错，不会解出一堆乱码。CBC 会按 PKCS#7 补齐 1–16 字节的填充，CTR 把 IV 当作整块 16 字节的计数块（可指定低 32/64/128 位自增）。
- 口令加密一段文字：「密钥来源」选口令 PBKDF2，填口令、迭代次数保持默认（这一项在「高级」折叠里），模式选 GCM，点「加密」；把结果整段贴到密文框、用同一个口令点「解密」即可原样还原。密钥区右侧实时写着你填的密钥是多少字节、合不合所选位长。
- 与 openssl 等工具对拍：「封装」切到裸密文（折叠会自己展开），把密钥、盐、IV 都手工填成固定 Hex，输出格式选 Hex，得到的就是标准 AES-CBC/PKCS#7 或 AES-CTR 密文；对端用整块 128 位计数器时把「CTR 计数位宽」改成 128。裸密文不保存 IV：解密前必须在「高级」里把加密时那个 IV 原样填回来，本站不会随机造一个 IV 去解（那只会解出一堆乱码），留空会直接报错并展开这块。
- 核对格式与安全性：输出下方的解析表列出头部、盐、IV、密文、认证标签各自的字节数与十六进制值，可直接确认长度是否合法；每次加密都会换一个新 IV，绝不复用。
常见问题
为什么没有 ECB 模式？
因为 WebCrypto 的算法注册表里就没有 AES-ECB——传 {name:"AES-ECB"} 会抛 NotSupportedError。这刻意如此：ECB 对每个明文块独立加密，相同的明文块必定得到相同的密文块，一张位图加密后轮廓还在，字符串里的重复字段也会被一眼看出，标准文档（NIST SP 800-38A）也从不推荐用它保密数据。本站不会在 CBC 上手搓一套「假 ECB」来凑功能：那既不是标准 ECB、也没法和其他工具互认，只会误导使用者。需要保密就选 GCM（带完整性校验）或 CBC/CTR，并把 IV 每次都换新的随机值。
GCM 的 IV 为什么不能重用？能不能填自己想要的 IV？
不能重用。GCM 的安全性依赖「nonce（即 IV）在同一把密钥下唯一」：IV 一旦与同一密钥重复，计数器序列就会重复，两段密文相当于用同一次一密异或，攻击者能直接消掉密钥恢复出明文关系，还能反推认证密钥 H 从而伪造签名——这是真实发生过的破法（Google 的 TLS 实现就因随机数缺陷出过事）。本站把 IV 长度固定为 12 字节（96 位），这是规范保证所有实现都支持的长度，实测非 12 字节的 IV 在部分引擎上会直接报 OperationError 或走极慢的回退路径。IV 不需要保密，可以让工具随机生成；只有为了跟别的工具对拍才手工填，填了就要自己保证这串 IV 在这把密钥下只用一次。
KCES 自带头里依次写着什么？
14 字节头部依次写着魔数 KCES、版本 1、模式编号、密钥字节数、密钥来源（0=原始密钥、1=口令派生）、4 字节大端迭代次数、盐长度与 IV 长度，随后依次是盐、IV 和密文（GCM 的认证标签仍在最末尾）。界面上的格式解析表会把每一段的长度逐行列出。
折叠起来的「高级」项还参与计算吗？
首屏只留密钥区、明文/密文两栏与结果，封装、盐、IV、迭代次数、CTR 计数位宽这五项收在「高级：手工盐与 IV、对齐 openssl enc」折叠里——收起不等于停用，这几个值哪怕折起来也照样被每次加/解密读取，只有被标灰并写明「不生效」的那几项才是当前模式下读不到的（比如密钥来源选原始 Hex/Base64 时不走 PBKDF2，盐与迭代次数就参与不了计算）；切到裸密文会自动展开，解密失败信息里点到盐/IV/迭代/CTR 时也会自动展开。
迭代次数该填多少？我自己给的口令够安全吗？
OWASP 口令存储 cheat sheet 对 PBKDF2-HMAC-SHA-256 的建议是至少 600000 次，本站默认 150000——因为浏览器主线程上的派生要几百毫秒到一秒以上，取个仍可用又不至于卡住页面的值，你可以在「高级」折叠里的迭代次数输入框把它调到 600000（上限 5000000 以免长时间无响应）。要清楚两件事：其一，加密强度上限由口令决定，「correct horse battery staple」这类长随机口令远比 12 位密码可靠，短口令在任何 KDF 下都能被离线字典攻击；其二，PBKDF2 只耗 CPU，不抗 GPU/ASIC，真正的长期保密建议用 Argon2id 或把数据交给成熟工具（age、gzip+openssl enc 等），网页工具适合临时保护和格式核对，不适合当保险箱。
对应功能编号 #30无需安装，手机端同样可用按 Ctrl + K 换工具