AES 联调失败时问题通常不在“AES-256 是否足够强”而在双方没有使用同一组参数。同一段明文只要密钥长度、工作模式、填充、IV、字符编码或密文编码有一项不同解密结果就可能乱码或直接报错。本文以常见的 CBC、ECB、CFB、OFB、CTR 模式为例梳理 AES 参数的含义、口令与原始密钥的区别以及前后端联调时应该逐项确认的内容。1. AES-128、AES-192、AES-256 的数字是什么数字表示密钥长度算法密钥长度字节数AES-128128 bit16 bytesAES-192192 bit24 bytesAES-256256 bit32 bytesAES 的分组长度始终是 128 bit也就是 16 字节。AES-256 并不意味着分组变成 256 位。“字符数”和“字节数”也不能混为一谈。16 个 ASCII 字符通常是 16 字节但 16 个中文字符的 UTF-8 编码远不止 16 字节。原始密钥模式应按解码后的真实字节长度校验而不是只看输入框字符数。2. 口令模式与原始密钥模式不是一回事口令模式用户输入一段容易记忆的 passphrase程序再通过派生过程生成真正的 Key 和 IV。CryptoJS/OpenSSL 兼容的口令模式通常还会在密文中携带随机 Salt所以同样的口令和明文多次加密可能产生不同结果。联调时仅告诉对方“口令是 abc123”不够还要统一Salt 的生成和存储格式密钥派生算法及参数最终密文的封装格式字符编码和输出编码。原始密钥模式双方直接约定固定长度的 Key并在需要时单独提供 IV。这种方式参数更直观但密钥的生成、分发、轮换和存储都必须由调用方负责。口令不能通过截断或补零就安全地变成 AES Key。生产系统应使用经过审查的 KDF 和随机 Salt并把派生参数写进协议。3. 五种常见工作模式CBCCBC 使用前一个密文分组影响下一个分组第一个分组需要 IV。它应用广泛但 AES-CBC 本身只提供保密性不提供完整性。攻击者可能在不知道密钥的情况下篡改密文造成可预测的明文变化。如果协议必须使用 CBC应再配合独立的消息认证机制并采用 Encrypt-then-MAC 等经过验证的组合。新协议通常更适合直接选择成熟的 AEAD 模式例如 AES-GCM但需要注意本文配套工具当前不支持 GCM。ECBECB 将每个分组独立加密相同的明文分组会产生相同的密文分组可能暴露数据结构。它不需要 IV但不适合保护生产环境中的结构化数据、文件或长文本。ECB 常见于遗留系统兼容和算法教学。能够成功解密不代表方案安全。CFB 与 OFBCFB 和 OFB 把分组密码转换为类似流密码的工作方式通常不需要传统意义上的块填充但必须使用正确且不可随意复用的 IV。双方还要确认反馈段大小等实现细节。CTRCTR 通过递增计数器生成密钥流易于并行处理。相同 Key 下绝不能复用相同的计数器/IV否则不同密文之间可能泄露明文关系。CTR 同样不自带完整性保护。4. IV 的作用和常见误区除 ECB 外上述模式都需要 IV。常见 AES 接口要求 16 字节 IV因为 AES 的分组大小是 16 字节。IV 通常不需要保密可以与密文一起传输但它必须符合对应模式的唯一性或不可预测性要求。以下做法都值得警惕永久把 IV 写死为 16 个零把 Key 的前 16 字节直接当 IV加密时随机生成 IV却没有与密文一起保存解密时使用新的随机 IV把十六进制字符串的字符长度误当作字节长度。例如32 个十六进制字符代表 16 字节。双方必须明确 Key 和 IV 输入是 UTF-8 文本、Hex 还是 Base64。5. Pkcs7、NoPadding 和 ZeroPaddingAES 每次处理 16 字节分组。CBC、ECB 等模式遇到不足一个分组的明文时通常需要填充。Pkcs7Pkcs7 会根据缺少的字节数补齐数据。即使原文长度刚好是 16 的倍数也会再增加一个完整填充分组以便解密端无歧义地移除填充。Java 中常见的AES/CBC/PKCS5Padding在 AES 场景下通常与其他库所称的 Pkcs7 兼容但仍应通过测试向量确认。NoPadding不做填充。对于要求整块输入的模式明文字节长度必须是 16 的倍数否则会失败。这里判断的是编码后的字节长度不是字符串长度。ZeroPadding用0x00补齐。若原文末尾本来就包含零字节解密端可能无法确定哪些零属于数据、哪些属于填充因此协议中必须明确原始长度或数据格式。6. Base64 和 Hex 只是密文的外层表示AES 输出的是二进制字节通常再编码为 Base64 或 Hex 以便传输明文字符串 - UTF-8 字节 - AES 加密 - 密文字节 - Base64 或 Hex 文本解密必须严格反向执行先按 Base64/Hex 还原密文字节再调用 AES最后按 UTF-8 等约定字符集解释明文字节。如果一方输出 Hex另一方却按 Base64 解码即使 Key、IV、模式完全一致也不会成功。7. 一张联调清单解决大多数问题前后端应将以下参数作为协议的一部分而不是在群聊中零散约定参数示例算法/密钥长度AES-256Key 来源32 字节原始 KeyHex 输入工作模式CBCIV随机 16 字节放在密文前部填充Pkcs7明文字符集UTF-8密文表示Base64认证方式HMAC-SHA-256 或协议指定 AEAD数据封装版本号 IV ciphertext tag然后建立固定测试向量使用同一份明文、Key、IV 和期望密文在两端分别加密和解密。固定 IV 只用于测试向量不能因此在生产中复用。调试时可使用 Tool-Tic AES 加解密工具 在浏览器本地切换 AES-128/192/256、CBC/ECB/CFB/OFB/CTR、Pkcs7/NoPadding/ZeroPadding以及 Base64/Hex 输入输出。它还区分 CryptoJS/OpenSSL 兼容的口令模式和 Key IV 原始密钥模式。工具适合验证参数不应被当作生产密钥管理系统不要把正式密钥粘贴到不受控环境。8. 安全设计不能止于“能解密”AES-CBC、CTR 等模式本身不能证明密文未被修改。生产协议还要解决消息完整性与身份认证随机数质量和 IV/nonce 唯一性密钥生成、权限隔离、轮换和吊销重放攻击错误信息是否形成 Padding Oracle算法版本升级与历史数据迁移。不要自行设计密码协议。优先使用平台提供的成熟 AEAD API、标准数据封装和专业密钥管理服务。遗留接口无法更改时也应把现有参数、风险和补偿措施记录清楚。结语AES 联调的关键不是反复尝试不同按钮而是把每一层都写成确定的协议Key 如何得到、IV 如何生成、使用哪种模式和填充、字节如何编码、密文如何认证。只有参数一致、密钥管理可靠并具备完整性保护“能够解密”才有安全意义。