AES 加密解密完全指南：GCM、口令派生与本地示例

更新 2026-08-09 约 14 分钟 隐私安全 How-to

要把一段配置草稿、备份备注或联调密钥「先锁住再带走」，而不是只做 Base64 或哈希时，需要的是对称加密。本指南对照 WebUtils 的 AES 加密解密页，讲清 AES-GCM、口令派生、密文结构与加解密往返示例，并标明工具边界：适合本地文本保护与教学演示，不是企业密钥托管或整盘加密产品。

立即使用相关工具 AES 加密解密 — 浏览器内 AES-GCM + PBKDF2，本地处理
打开工具 →

核心一句话

AES 在正确模式下用密钥把明文变成不可读密文；同一密钥（或同一口令派生结果）才能解回。 它可逆，所以能保密；它依赖密钥与参数约定，所以「算法选对了」却「口令弱、格式乱切、密钥长度不一致」照样解不开或等于没保。

主工具：AES 加密解密。需要多模式（GCM/CBC/CTR）对照时，可另开 文本加密解密，但两页密文格式不同，默认不互通。

AES 解决什么、不解决什么

AES（Advanced Encryption Standard）是分组对称加密算法：加密与解密使用同一密钥材料。常见密钥长度是 128 位 与 256 位（本页下拉对应 AES-128 / AES-256）。算法本身只定义「块怎么变换」；真正决定工程安全性的，还有：

维度 含义 本页做法
工作模式 如何把多块明文安全地串起来 固定 AES-GCM
初始化向量 IV 同密钥下区分不同消息 每次加密随机 12 字节
认证 密文被改了能否发现 GCM 自带认证标签（约 16 字节）
密钥从哪来 用户记不住 32 字节随机钥 口令 + PBKDF2 派生
输出形态 如何在文本通道里携带二进制 Base64 或 Hex 打包串

不是 Base64。 Base64 谁都能解码；AES 没有密钥（或口令）就应无法得到明文。详见 Base64 指南 与工具 Base64 编码解码。

不是哈希。 哈希是不可逆指纹，适合完整性校验；AES 是可逆保密。文件下载核对请用 Hash 生成器，不要用 AES「代替校验码」。

不是访问控制。 加密后的串仍可被复制、转发、长期存放。谁拿到密文 + 弱口令，谁就能暴力尝试。HTTPS、权限、审计仍要单独设计。

不是「把密码存进 AES 就安全」。 用户登录口令应使用慢哈希（bcrypt/scrypt/Argon2 等）做验证，而不是用 AES 可逆加密后入库再在业务里随时解密——除非你有明确的「可恢复密钥托管」产品需求与合规方案。

GCM 为什么是本页默认

GCM（Galois/Counter Mode）同时提供机密性与完整性：解密时若密文、IV 或认证标签被改动，Web Crypto 会失败，而不是默默吐出乱码明文。对浏览器内「文本加解密」演示与草稿保护，这比「只加密不认证」的旧习惯更稳妥。

CBC、CTR 在兼容旧系统时仍会见到：CBC 依赖正确填充与 IV 管理；CTR 依赖计数器/nonce 绝不重复。本站多模式页在 文本加密解密；本篇主工具专注 AES-GCM 单一管线，降低「算法选了 A、密文却按 B 解」的事故面。

口令、盐、IV 与密文长什么样

本页脚本路径（与页面安全说明一致）可概括为：

  1. 用户输入 明文 与 口令，选择密钥长度（128/256）与输出格式（Base64/Hex）。
  2. 生成随机 salt（16 字节） 与 IV（12 字节）。
  3. 用 Web Crypto：importKey 把口令当 PBKDF2 材料 → deriveKey（SHA-256，约 100000 次迭代）得到 AES-GCM 密钥。
  4. crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, utf8Bytes)。
  5. 把二进制按固定顺序拼接后编码输出：
salt(16B) + IV(12B) + ciphertext_and_tag

其中 GCM 的认证标签通常附在密文末尾（实现依赖 subtle.encrypt 的默认 tag 长度，页面说明为 16 字节量级）。解密时必须同一口令、同一密钥长度、同一输出格式解读，再按字节切分：前 16 为盐、接下来 12 为 IV、其余为待解密数据。

为什么每次加密同一句话，密文都不同

因为 salt 与 IV 每次随机。这是预期行为：

  • 相同明文 + 相同口令 → 密文串仍应不同（防「密文相同即明文相同」的泄漏）。
  • 解密不依赖「记住上次密文长什么样」，只依赖口令与打包格式。
  • 若你看到两次结果完全一致，反而要怀疑是否误用了确定性编码，或复制错了字段。

口令强度仍决定上限

PBKDF2 提高「从口令猜密钥」的成本，不能把「123456」变成军用级密钥。建议：

  • 口令长度与随机性参考 密码生成器；
  • 口令与密文分通道传递（例如密文走邮件，口令当面/电话/已建立的加密 IM）；
  • 不要把口令写进同一份「加密结果.txt」里一起发。

加密解密可操作步骤

工具页：AES 加密解密。计算在浏览器本地完成；请在 HTTPS 或 localhost 等安全上下文使用，否则 crypto.subtle 可能不可用。

A. 加密一段文本（推荐默认）

  1. 打开工具，确认顶部模式为 加密（🔐 加密 标签为激活态）。
  2. 在 明文 文本框输入要保护的内容（先用非敏感样例练手，例如 项目备注：周五前只给内网看）。
  3. 在 密码 框输入口令；可用「显示」核对是否打错，确认后再改回隐藏。
  4. 密钥长度 默认选 AES-256；无特殊兼容需求不要降到 128「图省事」——本页 128/256 都走 GCM，差异在密钥空间。
  5. 输出格式 选 Base64（人类粘贴、放进 JSON 字段更常见）或 Hex（只含 0-9a-f，某些日志系统更友好）。
  6. 点击 加密。下方 密文 出现长串；错误 区应为空。
  7. 点 复制 带走密文。用完点 清空，并考虑清理剪贴板。

B. 解密密文（往返验证）

  1. 切换到 解密 标签：输入标签变为「密文」，按钮变为「解密」。
  2. 粘贴完整密文（不要擅自插入空格、换行、引号，除非你确定传输层加了且对方会去掉——本页按整串解码）。
  3. 填入加密时同一口令；密钥长度、输出格式必须与加密时一致（Base64 密文不要用 Hex 去解）。
  4. 点 解密。成功则输出区为 UTF-8 明文；失败见下文错误表。
  5. 建议养成习惯：加密后立刻在同一浏览器做一次解密自测，再发给协作方。

C. 最小可复现示例（心智模型，非固定密文）

因 salt/IV 随机，无法在文档里写死「这句话永远对应某一串 Base64」。正确示范是流程，不是死记结果：

步骤 你输入 / 选择 期望
1 明文：hello-aes-demo —
2 口令：自拟长随机串（演示可用临时强口令） —
3 AES-256 + Base64 → 加密 得到一长串 Base64
4 模式改解密，同一口令/长度/格式 回到 hello-aes-demo
5 故意改口令末位再解 失败提示，而非乱码明文
6 故意删掉密文中间几个字符再解 失败（格式或认证失败）

若第 4 步失败而第 3 步成功，优先查：是否还停留在加密模式、是否密钥长度被改、是否复制时截断了字符串。

能力边界（对照真实页面）

  • 有： AES-GCM；AES-128/256；口令 + PBKDF2；随机盐与 IV；Base64/Hex 输出；加密/解密模式切换；复制、清空、口令显示切换；本地 Web Crypto。
  • 没有： 文件/文件夹批量加密、密钥文件导入导出、HSM/KMS、多人共享密钥策略、与 OpenSSL 命令行默认参数的一键兼容开关。
  • 不与 文本加密解密 的「算法前缀打包」默认互通——换工具前先在同一页完成往返。

常见失败与对照

现象 常见原因 处理
提示「请输入内容」 明文/密文框为空或只含空白 trim 后重试；注意全角空格
提示「请输入密码」 口令框为空 解密也必须填口令；本页不支持「无口令密钥文件」路径
解密失败：密码错误、密钥长度不一致或密文格式不正确 口令错、128/256 选反、Base64/Hex 选反、密文被截断/改写 逐项对齐加密参数；用原密文完整复制；不要混用两页工具的输出
加密失败且提到 subtle / 安全上下文 非 HTTPS、过旧浏览器、企业策略禁用 Web Crypto 换现代浏览器与安全源；勿在不支持的环境硬解
同口令「有时能解有时不能」 两段密文来自不同工具或不同格式；或剪贴板合并了两段 只保留一段完整打包串；确认格式下拉
密文「看起来像 Base64」但解失败 其实只是普通 Base64 编码，不是本页 salt+IV+密文结构 先判断来源；普通编码用 Base64
中文加密后再解乱码 极少见本页路径（UTF-8 TextEncoder/Decoder）；更常见是下游又用错误字符集显示 在本页直接解验证；避免二次转码
把密文再 Base64 一次后解失败 多包了一层编码 只保留本页输出；或先解外层 Base64 再贴回
公共 Wi‑Fi 下「本地工具」仍不放心 本地计算不上传，但屏幕分享、恶意扩展、页面被注入不在本工具保证范围 敏感内容用可信设备；装扩展需谨慎
忘记口令 对称加密无后门 无法由本站「找回」；只能重新加密明文备份

建议排错顺序

  1. 确认模式是解密，且口令、密钥长度、输出格式三件套与加密一致。
  2. 确认密文完整、无额外引号与 AES-GCM: 等外站前缀（那是另一页的格式）。
  3. 用同一浏览器、同一页做「加密 → 立刻解密」缩小环境差异。
  4. 仍失败则换非敏感短明文重走一遍，排除「原文本身含不可见字符」干扰。

真实工作场景

场景 A：把配置片段交给同事，但不走明文邮件

运维要把一段临时连接说明交给远程同事。用本页 AES-256 + Base64 加密，密文贴工单；口令通过已建立的语音或企业 IM 单独说。对方用同一页解密。约定写进消息：「WebUtils AES 加密解密页、GCM、256、Base64」。不要只说「我 AES 了一下」——对方可能打开多模式页或桌面 OpenSSL，参数对不上必败。

场景 B：本地日记/草稿防「肩窥」与误传

在共享电脑写未完成的个人备注：写完加密，只保留密文文件；离开前清空页面。这降低「屏幕没关、文件管理器预览明文」的风险，但挡不住木马与磁盘取证级别对手——预期要诚实。

场景 C：对比「编码 vs 加密」给新人培训

同一句 demo-secret：

  1. 在 Base64 编码 → 任何人可解；
  2. 在本页 AES 加密 → 无口令应失败；
  3. 在 Hash 做 SHA-256 → 不可逆。

三步并排，比讲一小时概念更有效。培训只用假数据。

场景 D：接口文档里的「AES 加密字段」联调

后端说「AES 加密后 Base64」。先问清：模式（GCM/CBC）、密钥是原始字节还是口令派生、IV 是否前置、tag 是否拼接、迭代次数。本页是「口令 + PBKDF2 + 固定打包」。若对方是「固定 16 字节密钥 + 独立 IV 字段」，不能指望本页密文直接打进接口。本工具适合你在浏览器侧理解 GCM 行为，或保护你自己的联调笔记，而不是假装兼容所有后端方言。

场景 E：从弱方案迁移

历史系统把「敏感字段 Base64」或「可逆自制 XOR」当加密。迁移期可用本页保护导出的迁移清单，同时规划服务端正式加密（信封加密、KMS、字段级方案）。本页不负责批量改库。

场景 F：口令太弱导致「加了等于没加」

有人用 111111 加密客户名单再上传网盘。攻击者下载密文后可离线猜测。加密前用 密码生成器 生成高熵口令，并启用密码管理器存储；需要评估已有口令可看 密码强度（若站点提供）。

安全与隐私清单

  • 默认只处理你有权处理的数据；生产密钥、证件号演示请脱敏。
  • 本页强调数据不上传；仍受浏览器扩展、XSS、屏幕录制、供应链脚本影响——「本地」≠「绝对安全」。
  • 公共电脑：用完 清空，退出前清理剪贴板；不要点「记住密码」类浏览器提示把演示口令存进个人资料。
  • 密文可公开传输不等于可公开讨论口令；分通道。
  • GCM 发现篡改会失败，这是特性；不要为了「解出点什么」关掉认证或改用无 MAC 的模式，除非你完全清楚后果。
  • 迭代次数与打包格式是本页约定；写进你们团队的内部备忘，避免一年后无人能解历史密文。
  • 法律与合规：加密不能替代最小必要原则与授权；跨境与行业数据另有规范。
  • 需要防篡改但不需保密时用哈希/签名；需要可逆保密才用 AES。

常见问题

AES-128 和 AES-256 在本页该怎么选？

无兼容包袱选 AES-256。两者都是 GCM；256 位密钥空间更大，现代浏览器开销对短文本可忽略。真正要担心的通常是口令熵与密文保管，而不是「128 会不会立刻被量子电脑当场拆开」这类空泛焦虑。若协作方系统写死 128，再改下拉并写进约定。

为什么加密结果不能当密码存在数据库里给用户登录用？

登录验证需要的是「服务器能否确认你知道口令」，不是「服务器随时能还原口令」。可逆加密意味着服务器（或拿到库+密钥的人）能读出用户口令，扩大泄露面。密码应用慢哈希；AES 用于保护数据载荷。

密文里已经包含盐和 IV，还会不会不安全？

盐与 IV 的设计目标通常是可以随密文传递（本页即打包在一起），保密性靠密钥/口令。不安全的是：IV/nonce 在同密钥下重复使用、盐固定且口令极弱、或把口令与密文绑在同一文件名里。随机盐/IV 每次不同是加分项。

和 OpenSSL、CyberChef、另一语言库的结果对不上？

几乎总是参数方言问题：PBKDF2 迭代次数、盐长度、IV 长度、是否 GCM、tag 长度、输出是否仅密文不含盐、字符编码是否 UTF-8。本页是固定管线；跨工具互通必须逐项对齐，而不是假设「都叫 AES 就能解」。

解密失败时会不会泄漏明文的一部分？

GCM 认证失败时，Web Crypto 应拒绝产出明文，这是刻意行为。你看到的是错误提示，而不是「半段乱码」。不要自己改脚本去掉验证「方便调试」后还把改过的页面当生产工具。

可以加密图片或 PDF 吗？

本页交互面向文本框。把二进制当文本硬贴会损坏。需要文件级保护应使用专门的文件加密工具或系统磁盘加密；若只是小段 Base64 文本载荷，先明确体积与下游是否按文本处理。不要把数兆 Base64 塞进本页当网盘加密器用。

浏览器本地加密，公司代理或扩展能看到明文吗？

计算在页面 JS 中完成前，明文存在页面内存与 DOM 中；恶意扩展、被注入的脚本、屏幕共享可以接触明文。本地不上传只约束「本站服务器不接收你的明文」，不约束你的整台浏览器信任链。高敏感场景用加固环境与正式产品。

继续浏览

用一句非敏感中文走通「加密 → 复制 → 解密 → 改错口令应失败 → 清空」，再读一遍密文结构说明，即可建立正确心智模型。把团队约定写成「工具 URL + GCM + 密钥长度 + 输出格式 + 口令通道」，比口头「AES 一下」可靠得多。

打开 AES 加密解密 多模式文本加密 返回指南列表 全部工具