AES解密报错：填充长度与块大小不匹配问题求助

核心问题分析 #

报错The ciphertext has an invalid padding length (31) compared to the block size (16)说明：解密后的最后一块数据不符合PKCS#7填充规则（PKCS#7填充值范围必须是1~16）。大概率是前端加密数据的编码/传输环节出错，或后端解密时的密钥/IV/模式与前端不一致导致的。

故障排查与解决步骤 #

1. 校验加密数据的编码与传输一致性 #

• CryptoJS默认输出的WordArray对象，直接调用toString()会生成Base64编码字符串，后端必须用Base64解码。如果前端用了Hex或其他编码，后端要对应处理。
  • 前端示例（明确指定Base64编码）：

    const encryptedData = CryptoJS.AES.encrypt(plaintext, key, { iv: iv }).toString(CryptoJS.enc.Base64);
    

  • 后端要确保解码方式匹配：比如用base64_decode()或phpseclib3的对应方法解析加密数据。
• 排查传输过程中的数据损坏：
  • 用XHR发送数据时，避免用application/x-www-form-urlencoded格式（会把Base64中的+转成空格），建议用FormData或JSON格式传输；如果必须用URL编码，前端要把Base64转成URL安全格式（+→-，/→_），后端再还原。
  • 对比前端发送的加密数据和后端接收的原始数据，确保完全一致，没有截断或转义。

2. 确认AES密钥的处理一致性 #

• AES-256密钥必须是32字节的二进制数据：
  • 后端解密RSA得到的密钥，要确保是原始二进制，而非Base64或UTF-8字符串。可以用strlen()（二进制安全）检查长度，必须等于32。
  • 如果前端是通过CryptoJS.lib.WordArray.random(32)生成的密钥，传输时要转成Base64，后端解码后再作为AES密钥使用。

3. 验证IV的正确性 #

• IV必须是16字节的二进制数据：
  • 前端传输IV时，同样要转成Base64或Hex，后端解码后检查字节长度是否为16。禁止直接传输WordArray转成的UTF-8字符串（会出现乱码，导致长度异常）。

4. 对齐AES模式与填充方式 #

• CryptoJS默认使用AES-CBC模式+PKCS#7填充，后端phpseclib3必须明确配置一致：

  use phpseclib3\Crypt\AES;
  
  $aes = new AES('cbc');
  $aes->setKey($decrypted_aes_key); // 确保是32字节二进制密钥
  $aes->setIV($iv); // 确保是16字节二进制IV
  $aes->setPadding(AES::PAD_PKCS7); // 明确指定PKCS#7填充
  $decrypted_data = $aes->decrypt(base64_decode($encrypted_data));
  

5. 最小化测试定位问题 #

• 写极简测试案例排除干扰：
  1. 前端只加密固定字符串（如"test"），输出加密数据、密钥、IV的Base64值；
  2. 后端直接用这些值解密，看是否成功。
  • 如果成功，说明问题出在RSA解密密钥环节或多字段加密的拼接逻辑；如果失败，说明基础的AES配置不一致。

常见坑点总结 #

• 前端把WordArray直接转成UTF-8字符串传输，导致二进制数据损坏；
• 后端解密RSA后未将密钥解码为二进制，直接用字符串作为AES密钥；
• 传输时未处理Base64的特殊字符（+、/），导致数据被篡改。

内容的提问来源于stack exchange，提问作者Quentin Régnier