Java/Kotlin中如何对多条同密钥AES密文实现单次批量解密

你当前的性能瓶颈和密文是否批量打包解密没有关系，核心问题是解密逻辑里做了大量重复的无效计算。

根因分析 #

你贴出的逐消息解密函数，每次调用都会重新执行一次65536轮的PBKDF2密钥派生，这是计算密集型操作，在安卓设备上单轮派生耗时通常在几毫秒到几十毫秒不等。如果一次解密几十上百条消息，仅密钥派生的耗时就会达到数百到数千毫秒，这才是卡顿的根本原因，AES加解密本身的计算量极小，哪怕逐条执行也不会有可感知的卡顿。

零结构变更优化方案（不需要修改数据库，不需要调整已存储密文格式） #

你不需要拼接明文、不需要修改存储结构、也不需要强行把密文打包做单次doFinal调用，只需要把固定不变的密钥派生逻辑从逐消息解密流程里抽离，批量解密时只执行一次即可，性能可以提升两个数量级以上。

实现代码 #

/**
 * 派生AES密钥，同一用户同一密钥只需要调用一次，不要在每条消息解密时重复调用
 */
private SecretKeySpec deriveAesKey(String secretKey, String username) throws GeneralSecurityException {
    SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
    KeySpec spec = new PBEKeySpec(secretKey.toCharArray(), username.getBytes(), 65536, 256);
    SecretKey tmp = factory.generateSecret(spec);
    return new SecretKeySpec(tmp.getEncoded(), "AES");
}

/**
 * 批量解密消息
 * @param encryptedList 已存储的密文列表，不需要做任何格式修改
 * @param aesKey 提前派生好的AES密钥
 */
private List<String> decryptBatch(List<String> encryptedList, SecretKeySpec aesKey) throws GeneralSecurityException {
    List<String> plaintextList = new ArrayList<>(encryptedList.size());
    // 固定IV和Cipher实例也可以复用，不需要每条消息重新创建
    byte[] fixedIv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
    IvParameterSpec ivSpec = new IvParameterSpec(fixedIv);
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING");

    for (String ciphertext : encryptedList) {
        cipher.init(Cipher.DECRYPT_MODE, aesKey, ivSpec);
        byte[] decodedCipher = Base64.getDecoder().decode(ciphertext);
        plaintextList.add(new String(cipher.doFinal(decodedCipher)));
    }
    return plaintextList;
}

调用方式 #

在需要解密一批消息的时候（比如打开聊天页加载历史消息），先调用一次deriveAesKey拿到密钥，再把密文列表传入decryptBatch即可，全程不需要修改已有的数据库结构，也不需要改动之前加密存储的密文格式，完全符合项目的设计冻结要求。

关于“单次doFinal解密所有密文”的说明 #

这种方案确实存在，但对你的场景来说完全没有必要：

• 如果要实现，你需要在解密前临时把所有密文做去填充拼接，处理不好很容易出现填充错误、明文乱码的问题
• 和上面的密钥复用方案比，这种实现带来的性能提升不足1%，完全感知不到
• 你当前所有消息都使用固定全0IV加密，本身每条密文都是独立的CBC加密块，逐条解密的开销只有Cipher初始化和doFinal调用，这部分耗时在移动端可以忽略不计

额外提示 #

你当前使用固定全0IV的实现存在安全风险，CBC模式要求每次加密使用独立的随机IV，否则会泄露明文的统计特征。这个改动属于安全优化，你可以在项目允许变更的阶段再调整，不影响当前的性能优化落地。

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