操作教程
如何在发送前加密敏感内容
用明文通过邮件发送密码列表、API 密钥或一段简短的机密信息，意味着任何拦截这条消息的人，或者之后能访问到该邮箱的人，都能直接读到内容。这份指南会生成一个强密码短语，并在本地用 AES-256-GCM 加密内容，这样通过邮件或聊天应用实际传输的，是一段无法阅读的密文，而不是一份放在别人服务器上、等着被扫描或复制的文件。
分步操作
- 打开密码生成器，把长度设为至少 20 个字符，启用所有字符类型，生成一个密码短语。先把它复制到一个临时的地方；你需要通过一个和传送加密内容不同的渠道把它告诉对方，比如打电话，或者用你们已经在用于其他事情的聊天应用。
- 打开 AES 加密工具，把要保护的文本（密码列表内容、API 密钥、配置文件，或任何简短的笔记）粘贴进输入框，再粘贴第一步生成的密码短语，然后点击加密。工具会用 PBKDF2 从你的密码短语派生出密钥，并用 AES-256-GCM 加密，两个步骤都在浏览器中完成，返回一段密文文本。
- 把这段密文直接粘贴进邮件正文或聊天消息里。不需要添加任何附件：敏感内容现在是以无法阅读的文本形式传输的。另外，通过其他渠道把密码短语告诉对方，并请他们把密文和密码短语粘贴进同一个工具，点击解密，即可还原出原始内容。
这和把文件上传到在线加密服务相比有什么不同
许多提供文件加密服务的网站，工作方式是先把你的文件接收到它们的服务器上，在那里加密，再让你下载结果：明文内容会经过一个你无法控制的系统，哪怕只是处理所需的短短几秒钟。这里的 AES 加密工具和密码生成器完全在你的浏览器中运行，使用 Web Crypto API：加密采用 GCM 模式下的 AES-256，密码短语用 PBKDF2-SHA-256 经过 310,000 次迭代拉伸成密钥，每次都会使用全新的随机盐值和初始化向量。整个过程中，明文、密码短语和密文都不会被发送到任何服务器。
在不破坏保护效果的前提下分享密码短语
只有当密码短语与密文分开传送时，加密才能真正起到保护作用。如果两者都发在同一封邮件串里，或者在同一个聊天里前后紧挨着发送，任何读到这段对话的人就能拿到破解所需的一切。可以在通话中口头念出密码短语，通过和传送密文无关的另一个聊天应用发送，或者对于真正敏感的内容当面告知。之后把它保存进密码管理器，而不是留在对话记录里。
这种方法覆盖不到的情况
AES 加密工具接受的是文本，上限大约 1 MB，而不是直接放入的任意二进制文件。它很适合密码导出文件、配置文件，或任何你能打开并复制为文本的内容。对于照片或小文档这类真正的二进制附件，可以先用 Base64 工具把文件转成一段文本，再手动去掉编码器加在前面的 data URI 前缀，然后按同样的方式加密这段文本。由于 Base64 会让数据体积膨胀约三分之一，实际能承受的文件上限会进一步缩小，因此只适合较小的文件。如果专门要保护一份 PDF，用 PDF 密码工具给文件加上真正的密码会更合适：它直接加密文档本身，也没有类似的文本体积限制。
本指南用到的工具
常见问题
密码短语或我要加密的文本，会被发送到服务器吗？
不会。密码生成器和 AES 加密工具完全在你的浏览器中运行，使用 crypto.getRandomValues 和 Web Crypto API 的 crypto.subtle。你输入的任何内容都不会在任何时候被发送到任何地方；你可以自己打开浏览器的开发者工具，观察网络面板，走一遍完整流程来验证这一点。
如果密码短语丢失了会怎样？
没有它，密文就无法恢复。这里没有找回选项，也没有后门：经过 310,000 次迭代的 PBKDF2，让暴力破解一个真正随机的 20 字符密码短语变得不切实际。请把密码短语保存在密码管理器里，而不是只留在你分享它的那段对话中，这样即便丢失那条消息，也不会因此失去内容本身。