AES 加密工具

AES 加密工具用一个密码加密文本，再解密还原，底层使用 AES-256-GCM，密钥由 PBKDF2 派生——全部通过 Web Crypto API 在你的浏览器内完成。不上传任何内容，不存储任何内容，也无需账户。它适合那些日常的敏感场景：通过聊天发送一段私密便签、在恢复码存入云端之前先备份、或者把凭据清单放在不那么显眼的地方。

使用方法

1. 选择模式：「加密」用于保护文本，「解密」用于还原内容。
2. 输入内容。 加密时输入明文；解密时粘贴你收到的完整 Base64 载荷。
3. 输入密码。 请使用足够长且唯一的密码——它用于派生密钥，且不会被存储。长度比替换符号更重要。
4. 运行并复制。 结果立即出现，请复制整段载荷。解密时，原文会回到输出框中。

点击按钮后发生了什么

整个流程很短，但值得了解，因为每一步都解释了你会观察到的某种行为：

1. 盐——生成一个随机值并随载荷一起保存，使同一个密码永远不会派生出两把相同的密钥。
2. 密钥派生——PBKDF2-SHA-256 对你的密码和盐运行 210,000 次迭代，故意做得慢，让暴力猜测变得昂贵。
3. IV——为本次加密创建一个全新的随机初始化向量。
4. 加密——AES-256-GCM 用派生出的密钥和 IV 加密你文本的 UTF-8 字节，并附加认证标签。
5. 输出——盐、IV 和密文被打包在一起并编码为 Base64，也就是你复制的那串字符。

反向过程执行同样的步骤，只是顺序相反：用密码和保存的盐派生出密钥，再用保存的 IV 解密并校验标签。标签不匹配时，工具会立即停止。

实操示例

示例 1——一条私密消息。 你需要通过聊天软件把账户信息发给家人。在这里加密文本，把 Base64 载荷发到聊天里，再通过电话把密码读给对方。日后即使有人拿到聊天记录，也只会看到密文。

示例 2——备份恢复码。 双重验证的恢复码总得存在某处，而云盘里的纯文本便签是薄弱环节。把清单加密，密文留在便签应用里，密码存进密码管理器。两半信息位于不同系统，攻破其中一个远远不够。

示例 3——工单里的共享密钥。 开发者需要经由 issue 跟踪系统把 API 密钥交给同事。先加密可以避免密钥进入跟踪系统的搜索索引和邮件通知。不要把密码写进同一张工单——请改用另一渠道。

它能防住什么，又防不住什么

只要密码通过独立渠道传递，它就能保护消息在传输途中或静止状态下的内容。它不能隐藏「你发送过某样东西」这一事实，也不能保护时间戳、收件地址等元数据，同样无法保护接收设备。如果对方机器已被攻破，解密后的文本就在终点暴露。而如果密码很弱，210,000 次迭代只能拖慢攻击者，救不了过短或可猜测的口令——加密的强度继承自你所选的密码。

如何设置密码

请使用较长的口令或随机生成的密码，并让每个加密对象使用不同的密码，这样单独一处泄露不会解锁全部内容。密码管理器是切实可行的做法：把加密密码存在里面，因为你无法为每一条便签都背下一个唯一且强壮的密码。当对方必须「输入」而非「粘贴」密码时——比如通过电话——优先选择由若干随机单词组成的口令，读出来不会有歧义。

常见错误

• 把密码和密文一起发送。 这是最致命的一条。请使用第二个渠道。
• 忘记密码。 没有重置。加密之前就把它写下来或存进密码管理器。
• 截断载荷。 复制完整的 Base64 字符串，包括结尾的 = 字符——少一个字符解密就会失败。
• 修改密文。 GCM 会认证整个载荷；聊天软件多加一个空格都可能让解密失败。粘贴失败时，请重新复制原样的字符串。
• 使用好记但很弱的密码。 无论 AES 密钥多长，加密强度都取决于口令本身。
• 以为解密报错就一定是密码错了。 也可能是载荷被改动。下结论前请先核对复制的内容。

功能特性

• AES-256-GCM 认证加密，可检测篡改
• PBKDF2-SHA-256 密钥派生，210,000 次迭代，随机盐
• 每次加密使用全新 IV——相同输入绝不产生相同输出
• 完整 UTF-8 支持，包括带重音的字符和 emoji
• 一键复制完整的 Base64 载荷
• 100% 客户端运行，基于 Web Crypto API——无上传、无日志、无存储

相关工具

• 密码生成器
• 密码强度检测
• 哈希生成器
• Base64 编解码