Salted__ 前缀 + MD5 派生密钥/IV），密文可用
openssl enc -d -aes-256-cbc -a（旧版、不加 -pbkdf2）解开。与后端「原始密钥 + 指定 IV」的实现不通用，那种场景请用 AES 工具。
一个页面里做两类计算，都基于 CryptoJS，全部在浏览器本地完成：
对称加密里的「密钥」是当作口令处理的。CryptoJS 沿用 OpenSSL 的传统做法：随机生成 8 字节盐，用 MD5 从口令派生出密钥和 IV，密文前面带 Salted__，整体再 Base64（所以密文形如 U2FsdGVkX1…）。
openssl enc -aes-256-cbc -a -d（旧版写法，不带 -pbkdf2），以及其它同样用 CryptoJS 的前端。| 算法 | 状态 |
|---|---|
| AES | 目前的标准，可用 |
| TripleDES | 尚可，但慢、块小（64 位），新系统别用 |
| DES / RC4 | 已被攻破，只为兼容老系统保留，别用于真正的保密 |
| MD5 / SHA1 | 可造碰撞，不能用于安全校验或存密码，仅做非安全用途的指纹 |
| SHA-256/512 | 安全的哈希 |
| Keccak | 以太坊等场景用的原始 Keccak，非 FIPS-202 SHA3 标准 |
| 存密码 | 用 bcrypt 或 scrypt，别用裸哈希 |
对称加密：切到「对称加密」→ 选算法（推荐 AES）→ 填口令 → 选「加密 / 解密」→ 执行。加密结果发给对方，对方用同样的口令和算法解密。
哈希：切到「哈希」→ 选算法 → 输入文本（边输入边算）；选 Hmac* 时要额外填 HMAC 密钥。
Q：这是真正安全的加密吗？ A：AES 本身安全，但安全性取决于口令强度和信道。这类"发到聊天软件的密信"只能挡一般人，别用它保护高价值机密。
Q：解密一直失败？ A：确认算法、口令完全一致，密文没有被截断或多了空格/换行，且确实是本工具（或兼容格式）加密的。
Q：这里的 Keccak 和"SHA3"是一回事吗？
A：不是。CryptoJS 的实现是原始 Keccak（以太坊 keccak256 用的那个），不是最终 FIPS-202 标准的 SHA3，两者填充不同、结果不同。需要标准 SHA3 请用 SHA 工具。
Q：数据会上传吗？ A：不会。加解密和哈希全部用浏览器里的 CryptoJS 完成，明文和密钥不发送到任何服务器。
相关：AES 加解密 · 3DES · DES · RC4 · MD5 · SHA · Keccak · HMAC · Base64 · bcrypt · scrypt。