17370845950

AES加密报BadPaddingException主因是密钥长度、填充方式或编码不一致；需确保密钥为16/24/32字节、加解密参数完全相同、IV固定或传输、统一UTF-8编码，并用java.util.Base64安全转换密文。

Java中用AES加密字符串为什么总报BadPaddingException

多数情况不是算法写错了，而是密钥长度、填充方式或字符编码不一致导致的。AES要求密钥必须是128/192/256位（即16/24/32字节），用SecretKeySpec构造时若传入的字符串没转成对应字节数组，就容易出错。

• 确保密钥是32字节（如用MessageDigest对原始字符串SHA-256哈希后取前32字节）
• 加解密必须用完全相同的Cipher实例化参数，例如"AES/CBC/PKCS5Padding"，不能一边用PKCS5Padding，另一边用NoPadding
• 初始化向量IV必须固定或随密文一起传输；若用SecureRandom每次生成新IV，解密时没保存它就必然失败
• 字符串编解码统一用StandardCharsets.UTF_8，避免new String(bytes)默认平台编码引发乱码

如何安全地把加密结果转成可存储的字符串

二进制密文不能直接当字符串用，常见做法是Base64编码。但别用sun.misc.BASE64Encoder（已废弃且非标准），改用java.util.Base64。

• 加密后调用Base64.getEncoder().encodeToString(cipher.doFinal(plainBytes))
• 解密前先用Base64.getDecoder().decode(encodedString)还原为字节数组
• 如果密文要存数据库或传HTTP，Base64是稳妥选择；若需URL安全，可用Base64.getUrlEncoder()

为什么用DES加密在Java 21里直接抛NoSuchAlgorithmException

JDK 17+默认禁用DES（含DESede），因为密钥太短、易被暴力破解。OpenJDK和Oracle JDK都已将其列为“insecure”，运行时策略文件java.security里jdk.crypto.disabledAlgorithms会拦截。

• 别再用KeyGenerator.getInstance("DES")，改用AES
• 如果必须兼容旧系统，可临时修改JAVA_HOME/conf/security/java.security，删掉DES相关条目（不推荐）

  

• 注意：即使启用，DES的56位有效密钥强度在现代计算下已无实际安全意义

加解密工具类要不要把Cipher实例缓存复用

不要缓存Cipher对象。它不是线程安全的，且内部状态（如opmode、iv）会在doFinal()后被清空或改变。

• 每次加解密都应新建Cipher：用Cipher.getInstance("AES/CBC/PKCS5Padding")
• 可以缓存SecretKey和IvParameterSpec（只要它们本身不变）
• 高频场景下，反复getInstance开销极小，远低于因共享Cipher导致的并发异常或解密失败

AES的密钥派生、IV管理、认证加密（如AES-GCM）这些环节一旦漏掉，表面能跑通，实际可能被篡改或重放。真要上线，别只套个Cipher.doFinal就完事。