AES 256 Decryption Online：解密失败排查清单

AES 解密失败，大多数时候不是神秘的密码学问题，而是配置不一致：key 不对、IV 漏了、mode 不同、padding 不同、把 Base64 当成 hex，或者复制密文时多了一个空格。

AES Encrypt 既能加密也能解密，所以可以用来在浏览器里检查一段疑似 AES-256 的值。安全用法是先排查设置，不是把生产敏感密文粘贴进去随机试。

先确认这里的 “AES-256” 到底指什么

AES-256 指 key size，但很多系统会把这个词说得很简略。它可能还要求特定的 mode、padding、IV 处理方式和输出表示方式。

解密前先收集完整配方：key 或 passphrase、mode、padding、是否有 IV、密文是 Base64 还是 hex。没有这些信息，解密失败不能证明密文本身坏了。

先检查密文表示方式

密文本质是字节，但工具通常显示成文本。如果值里有 `/`、`+`、`=`，可能是 Base64。如果只包含 `0-9` 和 `a-f`，可能是 hex。这只是线索，不是绝对判断。

在 AES 工具里选择和输入密文一致的输出编码。收到 Base64，就按 Base64 解密。收到 hex，就按 hex 解密。只有明确需要检查或转换表示方式时，才单独用 Base64 Encoder。

mode、IV、padding 要放在一起看

CBC、CFB、OFB、CTR、ECB 不是可以随便互换的标签。同一个 key，换一个 mode，结果可能完全不同。padding 也很重要，因为解密步骤必须知道原始明文最后一个 block 是怎么补齐的。

如果原值用 CBC 和 PKCS7 加密，就用 CBC 和 PKCS7 解密。如果原模式用了 IV，就粘贴同一个 IV。如果原来是 ECB，就不要为了填字段临时编一个 IV。

注意 OpenSSL 风格 passphrase 输出

一些 JavaScript AES 工具使用 passphrase 风格，而不是直接使用 raw key bytes。这可能生成带 salt 元信息的 OpenSSL 兼容输出。如果另一端库期待 32 字节 raw key，除非 key derivation 行为也一致，否则不一定能解开。

所以浏览器检查最好总是做双向验证：先加密一个很小的样例，再用同一组设置立即解密，然后对照另一端系统是如何派生 key、如何表示密文的。

真实数据前先比较小样例

两个系统不一致时，先造一个很小的已知明文，例如 `hello` 或假 JSON。用一个系统加密，另一个系统解密；如果可以，再反向做一次。

可以用 Text Diff 比较文档里的设置或样例输出。差异常常很明显：一边用 Base64，一边用 hex；一边包含 salt header；一边没有 IV；一边在加密前 trim 了空白。

可复用解密排查顺序

怀疑密文损坏前，先按这个顺序检查：

• 复制密文时不要带多余引号、空格或换行。
• 判断文本是 Base64 还是 hex。
• 确认 key 或 passphrase 完全一致。
• 选择文档要求的 AES mode。
• 只有原模式使用 IV 时才粘贴 IV。
• 选择相同 padding。
• 解密后，再用小样例做一次 round-trip。

如果小样例能通，真实值失败，问题多半在真实值本身：被截断、用了另一个环境的 secret、复制了外层包装文本，或上游加密配方不同。

安全提醒

不要为了测试解密，把客户数据、生产 token、私钥、session cookie 或未公开业务数据粘贴进浏览器工具。大多数集成问题，用同样配置的假密文就能排查。

如果必须调查敏感材料，使用批准过的本地流程，分享前脱敏，并避免把完整 key 出现在截图和工单里。

FAQ

为什么 AES-256 解密后是空白？

可能是 key 错、padding 不匹配、密文编码选错，或者这段值根本不是用同一套 AES 配方加密的。

hex 比 Base64 更安全吗？

不是。hex 和 Base64 只是字节的文本表示方式。安全性来自加密设计、key 管理以及 mode 和 IV 的正确使用。

可以用 AES 解密 hash 吗？

不可以。hash 是单向摘要。AES 只能在 key 和配置正确时解密 AES 密文。