跳到正文
DevTools / AES / RSA 加解密

AES / RSA 加解密

有时你需要通过一条不完全可信的通道把秘密交给同事，或者需要确认服务端产出的密文确实能被你手上的密钥解开。本工具执行真正的认证加密，底层是 Web Crypto API——浏览器用于 TLS 的同一套经过审计的原生实现——覆盖 AES-GCM、AES-CBC、3DES 与 RSA-OAEP，支持 RSA 密钥对生成，并明确说明哪些模式安全、哪些仅为了兼容而保留。

完全在浏览器本地运行——不会上传任何内容。

暂无内容

口令通过 PBKDF2-SHA256 派生为密钥，盐与迭代次数随密文一同保存。

工作原理

AES 是分组密码，分组长度 128 位，密钥长度 128、256（很少用 192）位。分组密码一次只能加密一个分组，处理更长的数据需要工作模式，而安全性正是在模式上被决定或被毁掉的。AES-GCM 是认证模式：除密文外还产出认证标签，解密时若标签不匹配就拒绝返回明文。仅这一条性质就击败了一整类攻击，因为攻击者在传输中翻转比特会引发硬失败，而不是悄无声息地被篡改。

GCM 需要一个 nonce（一次性使用的数值），通常为 96 位随机数。nonce 不是秘密，一般与密文拼接在一起。绝对关键的是同一个密钥与 nonce 的组合永不重复：一旦重复，就会泄露两段明文的异或值，更糟的是攻击者可以伪造标签。本工具每次加密都生成全新的随机 nonce 并与输出一同保存，这也是同一段文本加密两次会得到两个不同密文的原因。

CBC 是较旧的分组模式，只因为大量既有代码仍在使用而保留。它把每个分组链入下一个分组，需要初始向量，且与 GCM 的 nonce 一样必须不可预测。关键在于 CBC 自身不提供任何认证：攻击者可以翻转密文中的比特，并确切知道下一个明文分组中哪些比特会随之翻转。针对未认证 CBC 的填充预言攻击曾是若干重大数据泄露事件的成因。写新代码请用 GCM；必须用 CBC 时，应以独立密钥做 encrypt-then-MAC。

RSA 是非对称密码，解决的是另一个问题：加密方使用公钥，只有私钥持有者能解密。其数学基础是大素数乘积上的模幂运算，速度慢，且只能处理小于密钥长度的数据，因此 RSA 几乎总是用来加密一把对称密钥，再由该密钥加密主体数据。本工具实现 RSA-OAEP 配合 SHA-256，即取代了易受攻击的 PKCS#1 v1.5 的填充方案。密钥对使用浏览器 CSPRNG 在本地生成。

常见应用场景

  • 通过聊天工具把密码或 API 密钥发给同事，而不让明文出现在消息里。
  • 验证应用产出的密文能否用你配置的密钥正确解开。
  • 生成 RSA 密钥对，用于测试自家服务的签名或加密流程。
  • 用已知明文样本解密，反推遗留系统实际使用的 AES 模式与 IV。
  • 生成一小段 AES-GCM 测试向量，粘贴进单元测试。
  • 核对厂商文档中关于认证加密的描述与其 SDK 实际输出是否一致。

最后更新: 2026-10-14

常见问题解答

应该选择哪种模式？

除非有明确理由，否则选 AES-GCM。它是认证加密，篡改会被检测出来而不是被静默接受；速度快；并且在几乎所有现代 CPU 上都有硬件加速。AES-CBC 与 3DES 只为兼容既有系统而存在。3DES 尤其已经过时：64 位的分组长度使其在大数据量下容易受到生日攻击，NIST 自 2023 年起已将其废弃。

我输入的密码会被发送到哪里？

不会发送到任何地方。密钥派生、加密与解密全部通过 Web Crypto API 在浏览器内完成，也就是浏览器用于 HTTPS 的同一条原生代码路径。加密过程中页面不发起任何网络请求，打开开发者工具的网络面板即可看到它始终为空。不过要清楚，在共用或已被入侵的机器上输入的密码仍可能被键盘记录器和扩展程序获取，这是任何前端工具都无法防御的。

为什么不能用 RSA 加密大数据？

因为 RSA 只作用于一个小于模数的整数。2048 位密钥配合 OAEP-SHA256 最多加密 245 字节，4096 位密钥也只有 501 字节。标准做法是混合加密：随机生成一把 AES 密钥，用 AES-GCM 加密数据，再用 RSA 加密这把 AES 密钥并一同发送。TLS 和 PGP 都是这么做的，这也是为什么在实践中 RSA 看起来很“快”，尽管其底层原语很慢。

用错密钥解密时应该报错吗？

用 AES-GCM 时应该报错，这正是它的意义所在。错误的密钥会产生错误的认证标签，解密直接失败，而不是返回乱码。用 AES-CBC 时你得到的是填充错误或看似合理的乱码。如果某个系统在密钥错误时返回乱码而非报错，说明它使用了未认证的模式，值得进一步追问它还有哪些环节没有校验。

相关工具