文本加密
使用密码短语在本地对文本进行 AES-256-GCM 加密与解密。密钥仅由密码短语派生、绝不出浏览器，密文可放心分享，全程无任何数据上传。
使用说明
- 默认处于「加密」模式：在输入框粘贴需要加密的文本，支持中文、英文与 Emoji 等任意字符。
- 输入一个密码短语，点击「加密」按钮，下方会得到三段式密文：盐值.初始化向量.密文，可直接复制分享。
- 需要还原时切换到「解密」模式，粘贴完整密文并输入当初的密码短语，点击「解密」即可得到原文。
- 同一密码短语加密同一段文本，每次结果都不同（每次随机生成盐值与 IV），这是 AES-GCM 的正常安全特性。
- 本工具使用浏览器 Web Crypto API，必须在 HTTPS 或 localhost 等安全环境下运行。
常见问题
我的文本与密码会上传到服务器吗？
为什么同一段文本每次加密结果都不同？
忘记密码短语还能解密吗？
密文里的两个点号是什么？
使用步骤
- 选择加密或解密模式
顶部芯片默认选中「加密」，需要还原密文时点「解密」。两种模式共用同一个输入框与密码短语栏。
- 输入明文与密码短语
把要保护的文本粘进输入框，中英文与 Emoji 均可。在密码短语栏输入口令，点「显示」核对后再加密。
- 加密并保存密文结果
点「加密」按钮生成以点号分隔的三段式密文 salt.IV.ciphertext。用「复制结果」或「下载密文」保存与分享。
- 解密保持三段完整
切换到解密模式后粘贴完整密文并输入原口令。三段中任何一段缺失或被改动、口令错误都会导致解密失败。
- 妥善保管密码短语
密钥由口令经 PBKDF2 在本地派生且不保存，忘记口令便无法恢复原文，建议存入密码管理器。
工具详细介绍
AES-256-GCM 是主流的认证加密算法，加密的同时校验完整性。密文一旦被篡改，解密会直接失败，不会返回错误内容。本工具全部运算基于浏览器内置的 Web Crypto API。口令经 PBKDF2 以十万次迭代派生密钥，文本、口令与密文都不经过任何服务器。
适合把 API 密钥、恢复代码、私密笔记等敏感内容加密后存进网盘或聊天工具。双方没有安全信道时也能传递秘密：约定口令后，密文公开贴出也不泄露内容，没有口令无法还原。
原理与背景
AES 的前身是比利时密码学家设计的 Rijndael 算法，2001 年被 NIST 定为联邦加密标准 FIPS 197。密钥分 128、192、256 位三档，本工具取最强的 256 位。AES 与 GCM 都出自 NIST：GCM 模式定义在 SP 800-38D，属于认证加密。计数器模式负责加密，Galois 域上算出的认证标签负责完整性。密文被改动任何一个字节，标签校验都会失败，解密端直接报错，不会交出被篡改的明文。
口令不能直接当密钥用，需要先经密钥派生函数拉伸。本工具用 PBKDF2（RFC 8018）以 SHA-256 迭代十万次，把可记的口令映射成 256 位密钥。暴力枚举的成本因此明显抬高。盐值与 12 字节 IV 每次随机生成。盐让同一口令在不同密文里派生出不同密钥，IV 让同一密钥每次计数器起点不同。两层随机共同挡住预计算与彩虹表式攻击，也保证相同输入每次得到不同密文。GCM 对 IV 重复极其敏感，同一密钥下 IV 绝不能重复使用。
典型使用场景
- 交接敏感凭据给接手人
离职交接要把数据库口令、后台账号交给继任者，明文发到聊天里会永久留在记录中。用双方约定的口令加密后再发，口令另外通过电话或口头告知。
- 给配置文件里的密码再上一道锁
配置文件难免进入版本库或被打包分发，其中的第三方服务口令可以先用本工具加密。仓库里只保留密文，口令由部署时的人工步骤另行注入。
- 判断解密失败的真实原因
解密失败未必是口令输错：GCM 的完整性校验对截断与篡改一视同仁地报错。先检查密文三段是否齐全、有没有被换行打断，再回头核对口令。
使用技巧
- 同一文本同一口令，每次加密结果都不同，因为盐值与 IV 每次随机生成。
- 密文三段以点号分隔，分享时务必完整复制，缺失任何一段都无法解密。
- 页面需要 HTTPS 或 localhost 安全上下文，若按钮不可用请先检查地址栏协议。
注意事项
- 别把口令与密文放在一处
把口令贴在密文旁边、写进同一张便签或同一条聊天记录，等于把锁和钥匙一起交出去。口令与密文分开渠道存放，泄露面才可控。
- 弱口令会抵消强算法
十万次迭代能拖慢枚举速度，却挡不住「123456」这类口令被字典攻击迅速破解。算法强度与口令强度是两回事，长而随机的口令才是根基。
- 一套口令别用在所有密文上
多份密文共用同一个口令确实省事，但口令在一处泄露就全部沦陷。按用途分组设置口令，重要内容单独一套，把可能的损失范围控制住。