Bouncy Castle AES-256解密失败：大密文解密报pad block corrupted异常求助

你遇到的这个org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted异常，在使用PKCS7填充的AES解密场景里很常见，尤其是处理大密文时才触发的情况，结合你的代码来看，主要有几个核心问题需要排查：

1. 缓冲区未正确截断，导致无效字节干扰校验 #

你的process方法里，用bufferedBlockCipher.getOutputSize(input.length)创建了最大可能的输出数组，但doFinal方法会返回实际写入的字节数——你现在直接返回整个数组，没有截断到真实有效长度。

对于小密文来说，数组实际长度和有效长度差异很小，可能刚好不会触发PKCS7的填充校验失败；但大密文时，数组末尾会多出大量无效字节，这些字节会被当成填充块的一部分，导致PKCS7校验时判定填充损坏。

修正方案：
在doFinal后，根据实际写入的总长度（processBytes返回的tam加上doFinal返回的长度）截断数组：

import java.util.Arrays;
import org.bouncycastle.crypto.InvalidCipherTextException;
import org.bouncycastle.crypto.BufferedBlockCipher;
import org.bouncycastle.crypto.CipherParameters;

public byte[] process(byte[] input, BufferedBlockCipher bufferedBlockCipher, CipherParameters cipherParameters, boolean forEncryption) throws InvalidCipherTextException {
    bufferedBlockCipher.init(forEncryption, cipherParameters);
    byte[] rv = new byte[bufferedBlockCipher.getOutputSize(input.length)];
    int tam = bufferedBlockCipher.processBytes(input, 0, input.length, rv, 0);
    try {
        int finalLen = bufferedBlockCipher.doFinal(rv, tam);
        // 截断到真实有效长度
        return Arrays.copyOf(rv, tam + finalLen);
    } catch (InvalidCipherTextException e) {
        throw e; // 不要吞掉异常，直接抛出给调用者处理
    } catch (Exception e) {
        throw new InvalidCipherTextException("加解密处理失败", e);
    }
}

2. 默认使用ECB模式的隐患 #

你直接使用AESEngine，它默认是ECB模式——这是一种不安全的块加密模式，而且如果加密端使用了带初始化向量（IV）的模式（比如CBC、CTR），用ECB解密必然会导致块内容解密错误，进而破坏填充结构。

即使加密端也是ECB模式，大密文的块处理如果出现对齐问题，也更容易触发填充校验失败。

修正方案：
明确指定安全的加密模式（比如CBC），并确保加密和解密端使用相同的IV：

import org.bouncycastle.crypto.modes.CBCBlockCipher;
import org.bouncycastle.crypto.params.ParametersWithIV;

// 改用CBC模式，需要配合IV使用
BlockCipher blockCipher = new CBCBlockCipher(new AESEngine());
// 初始化时传入包含IV的参数（IV长度需等于AES块长度16字节）
byte[] iv = ...; // 需和加密端使用完全相同的IV，可随密文一起传输
CipherParameters cipherParameters = new ParametersWithIV(new KeyParameter(key), iv);

3. 大密文的完整性问题 #

大密文在传输或存储过程中，更容易出现字节丢失、篡改的情况，导致最后一个块的填充字节不符合PKCS7的规则（比如填充值不在1-16之间，或者填充长度与实际填充的字节不匹配）。小密文因为数据量小，这类问题出现概率低。

排查建议：

• 对比加密前后的密文哈希值，确认大密文没有被篡改或截断；
• 如果是网络传输，检查是否有分块传输时的拼接错误。

4. 异常处理逻辑不当 #

你的代码里捕获了Exception后仅打印堆栈，依然返回可能无效的rv数组，这会导致错误数据流入后续流程，掩盖真正的问题。应该直接抛出异常，让调用者能及时感知并处理错误。

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