服务间加密模式不一致
失败输入：发送端用 CBC，接收端按 GCM 解密。
失败表现：解密失败或完整性判断异常。
修复：把算法/模式/填充写成明确契约，并做跨语言向量测试。
AES 加密解密
使用 AES-GCM 对文本加密与解密
密码安全
🔒 100% 本地运行 — 你的数据不会离开当前页面由 ToolsKit 编辑团队维护•最近更新：2026年3月7日•最近复核：2026年3月13日
页面模式
输入
Quick CTA
先选加密或解密，填文本和密码直接运行；参数说明与错误对照留在 Deep。
输出
Encrypted payload
—🔒 100% client-side • Web Crypto API
下一步（Workflow）
页面阅读模式
Deep 展开踩坑、配方、片段、FAQ 与相关工具，适合排查问题或继续深入。
工具说明
该工具使用 AES-GCM 与 PBKDF2-SHA256（256 位密钥）完成文本加密，并输出 salt.iv.ciphertext 的可移植载荷格式。你也可以使用相同密码和迭代次数对载荷进行解密，适合安全笔记、密钥传输流程验证、接口加密联调等场景。所有计算都通过浏览器 Web Crypto 在本地完成，不会上传输入内容。
失败输入样例库
重复复用 IV/nonce
失败输入：多个消息共用同一个固定 IV。
失败表现：安全性显著下降，部分场景可预测性上升。
修复：每次加密都生成唯一 IV/nonce，并安全传递。
CBC 密文按 GCM 规则解析
失败输入：把 CBC 输出误当成携带 GCM tag 的格式处理。
失败表现：出现间歇性解密失败，错误日志误导定位。
修复：给密文格式加版本并显式绑定算法模式。
同 key 重复使用 IV
失败输入：同一密钥下多条数据共用固定 IV。
失败表现：密文模式泄露，安全性显著下降。
修复：每次加密都生成唯一随机 IV。
忽略认证标签校验失败
失败输入：解密流程不处理 auth tag 错误仍返回数据。
失败表现：被篡改密文可能被当作正常数据接收。
修复：tag 校验失败必须硬失败并停止处理。
快速决策矩阵
现代接口数据保护
建议选：优先采用带认证的模式（如 GCM）并严格管理 nonce。
谨慎用：非必要不要使用不带认证的旧模式。
必须兼容历史系统
建议选：仅在有补偿控制和迁移计划时使用旧模式。
谨慎用：避免跨客户端/语言混用参数配置。
为业务数据选择可落地 AES 策略
建议选：优先带认证的模式并严格管理 nonce/IV。
谨慎用：避免复用 IV 或跨服务混用模式假设。
新建应用层加密能力
建议选：优先 AEAD（AES-GCM）+ 唯一 IV + tag 校验。
谨慎用：避免无完整性保护的裸加密模式。
必须兼容旧 CBC 合作方
建议选：把兼容边界隔离并补显式 MAC。
谨慎用：避免把旧模式扩散到新系统。
生产可用片段
AES payload 形态
txt
salt.iv.ciphertext对比决策
编码 vs 加密
编码
适合只做格式转换或传输兼容。
加密
适合真正需要保密的场景。
补充：编码只是换表达形式，加密才是在做访问限制。
AES 可逆加密 vs 单向哈希
AES 加密
适合后续需要恢复原文的数据场景。
哈希
适合只做完整性校验或密码校验，不需要还原原文。
补充：加密可在持钥前提下还原，哈希设计上不可逆。
AES-GCM 认证加密 vs AES-CBC 历史模式
AES-GCM
现代系统需要同时保障机密性与完整性时。
AES-CBC
仅在历史系统短期无法迁移时。
补充：认证加密能显著降低多服务联动中的误用风险。
每消息随机 IV/nonce vs 固定 IV 复用
随机 IV/nonce
所有生产加密请求都必须采用。
固定 IV
仅用于受控测试向量和互通验证。
补充：IV/nonce 复用属于高风险且高影响的加密错误。
带认证加密 vs 仅加密不校验完整性
AES-GCM/AEAD
适合绝大多数现代应用数据保护。
旧模式仅加密
仅在兼容旧系统且额外有 MAC 时使用。
补充：只加密不验完整性，可能被静默篡改。
高频问题直答
Q01
AES 加密等于安全密钥管理吗？
不等于。再强的加密，也架不住弱密码和不安全的密钥传递。
Q02
为什么 payload 看起来像真的，但解密还是失败？
最常见是密码不对、salt/iv 结构坏了，或 payload 格式被破坏。
失败门诊（高频踩坑）
共享了太弱的密码
原因：密码一旦可猜测或被复用，再好的加密也会快速失去意义。
修复：使用强且独立的 passphrase，避免团队长期复用同一密钥。
同一密钥重复使用固定 IV
原因：IV 重用会泄露结构信息，显著削弱加密安全性。
修复：每次加密都生成随机 IV，并与密文一起保存/传输。
场景配方
01
加密一段短敏感文本
目标：把短文本加密成浏览器内可生成的 payload，用于更安全的临时传递。
- 切到 encrypt 模式并输入原文。
- 使用强密码，并确认生成结果格式。
- 如果要分享，尽量分开传 payload 和密码。
结果：你可以更方便地生成短小的加密结果，而不用离开当前页面。
02
在 QA 协作中安全共享敏感样本
目标：对测试载荷中的敏感字段加密，既能复现问题又不暴露明文。
- 准备脱敏样本并选择 AES 参数。
- 生成密文，通过独立通道传递密钥信息。
- 在目标环境解密并验证问题可复现性。
结果：排障协作可以继续推进，同时降低工单和聊天泄露风险。
03
加密上线前的跨端兼容校验
目标：确保前后端 AES 参数一致并可互通解密。
- 统一模式、密钥长度、IV 表达与填充策略。
- 用固定向量做双端已知答案测试。
- 补充篡改密文时的失败路径验证。
结果：上线后加密链路更稳定，排障成本更低。
04
密文存储与密钥轮换流程
目标：在支持密钥轮换的同时保证机密性与完整性。
- 每条记录使用随机 IV + AES-GCM 加密。
- 保存 key-id、IV、ciphertext、auth tag。
- 解密前按 key-id 取钥并强制校验 tag。
结果：即便轮换密钥，数据仍可安全解密且防篡改。
05
跨服务加密契约联调
目标：避免生产前出现加解密协议不兼容。
- 先约定算法、IV 长度、编码格式。
- 发布双向测试向量。
- CI 中强制通过契约测试再上线。
结果：跨服务加密链路更稳定。
实操指南
AES 加密解密 更适合放在真实输入与发布决策链路中使用，优先关注「现代接口数据保护」这类高风险场景。
适用场景
- 当场景是 现代接口数据保护 时，可优先采用：优先采用带认证的模式（如 GCM）并严格管理 nonce。。
- 当场景是 必须兼容历史系统 时，可优先采用：仅在有补偿控制和迁移计划时使用旧模式。。
- 在 编码 vs 加密 场景下先对比 编码 与 加密 再落实现。
快速步骤
- 切到 encrypt 模式并输入原文。
- 使用强密码，并确认生成结果格式。
- 如果要分享，尽量分开传 payload 和密码。
避免踩坑
- 常见失败：解密失败或完整性判断异常。
- 常见失败：安全性显著下降，部分场景可预测性上升。
常见问题
AES-GCM 适合文本加密吗？
适合。AES-GCM 是现代认证加密模式，在随机 IV 和正确实现下具有良好安全性。
为什么要使用 PBKDF2？
PBKDF2 可以把用户密码派生为更强的密钥，并通过盐和迭代次数提高暴力破解成本。
能解密其他系统生成的密文吗？
可以，前提是对方使用兼容的 AES-GCM 与 PBKDF2 参数以及相同的载荷格式。
密码忘了还能恢复吗？
不能。该工具不会也无法恢复丢失密码。
输入内容会上传到服务器吗？
不会。所有加密解密都在浏览器本地完成。
这个工具能替代正式密钥管理系统吗？
不能。它适合联调和日常加密处理，不应替代企业级密钥管理方案。