AES解密后数据大小与字节数异常问题排查求助

这种情况我之前在项目里踩过类似的坑，既然客户确认密码没问题，那可以从这些容易被忽略的方向入手排查：

• 编码转换的隐性错误
  很多时候问题出在字节与字符串的转换环节：比如加密完成后，你把字节数组转成字符串存储，但加密端用的是UTF-8编码，而解密端却用了ISO-8859-1或其他编码反向转换。如果加密字节里包含非UTF-8兼容的字节，错误编码会把单个字节拆成多个字符，再转回字节时就会出现长度膨胀。建议全程用字节数组处理加密数据，避免不必要的编码转换；如果必须转字符串，一定要两端统一用Base64（而非普通字符编码）。

• 加密数据在存储/传输中被篡改
  常见的场景包括：

  • 加密后的字节被自动做了Base64编码（比如存储到数据库的字符串字段时），但解密端没先做Base64解码就直接解密；
  • 反过来，加密端做了Base64编码，但解密端重复解码了一次；
  • 数据库字段类型错误：用了VARCHAR而非BINARY/VARBINARY，导致存储时自动补全或转码，改变了原始字节长度。
    可以让客户打印解密前输入的字节长度，对比加密后的原始长度（应该是32字节），如果输入长度不对，问题肯定出在数据传输/存储环节。

• 加密算法参数不匹配
  密码正确不代表所有算法参数都一致：

  • 填充模式：加密用了PKCS7Padding，解密却用了NoPadding，会导致解密后保留填充字节，长度超过32；或者加密没填充但解密强制填充，也会引发异常。
  • 初始向量（IV）不一致：像AES-CBC这类算法需要IV，如果加密和解密的IV不一样，解密结果会完全乱码，某些库的实现下可能输出异常长度的字节。
  • 密钥派生参数差异：如果密码是通过KDF（比如PBKDF2、Argon2）生成密钥的，两端的迭代次数、盐值（salt）、哈希算法必须完全一致，哪怕一个参数不同，生成的密钥就会不一样，解密结果必然乱码，长度也可能异常。

• 解密逻辑的输入重复或拼接
  检查客户的解密代码，有没有可能不小心把加密数据读取了两次，或者把两个不同的加密片段拼在一起传入解密函数？比如循环读取时没处理好边界，导致输入的字节流是原始的两倍（或部分重复），解密后就会得到更长的错误结果。加个日志打印解密前的输入字节长度，就能快速确认这个问题。

• 加密库的版本或实现差异
  不同语言、不同版本的加密库对算法的处理可能有差异：比如某些旧版本的库在处理错误解密结果时，不会抛出异常而是输出乱码字节，长度可能和原长不同；或者填充的处理逻辑不一致（比如某些库自动去除填充，某些需要手动处理）。可以让客户核对两端使用的加密库版本，以及算法的具体实现代码（比如AES的模式、密钥长度等）。

内容的提问来源于stack exchange，提问作者DevForRest