跳到正文

文本加密解密

Text Encrypt & Decrypt

用一个口令做 AES-GCM 加密,产出一段自带全部参数的 Base64 密文。

用一个口令把消息加密成一个能粘到任何地方的 Base64 字符串,再解密回来。AES-GCM 配 PBKDF2 派生的密钥;盐和 nonce 都在输出里,所以这个字符串就是完整的密文,没有别的需要保管。

🔒 完全在你的浏览器里运行encryptaescryptotext
模式

没有找回的办法。忘了口令,消息就没了;口令太弱,消息等于是公开的。

消息

加密结果(可以随处粘贴的 Base64)

用 PBKDF2 with HMAC-SHA-256 迭代 600,000次派生出的密钥来做 AES-256-GCM;每次新生成的 16字节盐和 12字节随机数都随输出一起走,所以这串 Base64 就是全部密文——别的什么都不用留。它和文件加密工具用的是同一种容器,全部在这个标签页里运行,被改动过的内容会被发现而不是被解开。用 PBKDF2 而不是 Argon2id,是因为浏览器自己实现的就是它;迭代次数取的是 OWASP 给它定的下限。

怎么用

  1. 选一个你不会弄丢的口令

    没有任何形式的找回。口令忘了,消息就没了;口令好猜,消息就公开了。

  2. 加密并复制 Base64

    它能经受邮件、聊天和文本文件——没有附件,没有密钥文件,没有需要放在旁边保存的东西。

  3. 用另一条路径发送口令

    口令和密文一起走,整件事就白做了。不同的渠道,最好是不同的日子。

常见问题

为什么用 PBKDF2 而不是 Argon2id?

因为 PBKDF2 是浏览器自己实现的,代码由平台维护。Argon2 意味着要带上一份 WebAssembly 构建,而一个你无法审计的密码学原语,比一个众所周知、按 OWASP 推荐迭代次数运行的原语更糟——这里用的正是后者。

口令错了会得到一堆乱码吗?

不会——它直接失败。AES-GCM 对密文做认证,所以口令错了或改动了一个字符,得到的是一个错误,而不是看起来像样的胡话。篡改会被检测出来,而不是被解密。

这是端到端加密吗?

这是你自己在自己的浏览器里、用一个别人都没有的密钥做的加密。它不是一个消息协议——没有前向保密,没有身份,没有密钥交换。持续的对话请用为此而造的工具。

文件加密工具能打开它吗?

能——特意用了同一个容器格式,所以两个工具能互相解密对方的输出。要审计的构造只有一个,而不是两个。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。