Java对称加密实战：AES与Cipher配置详解

本文深入剖析Java中AES对称加密的实战要点与常见陷阱，强调必须显式指定完整转换字符串（如“AES/CBC/PKCS5Padding”或“AES/GCM/NoPadding”），彻底摒弃不安全的ECB模式；详解CBC需随机IV、GCM对12字节IV和128位认证标签的严格要求，密钥必须精准匹配128/192/256位并经PBKDF2等安全派生，Cipher操作模式不可混淆、实例不可复用，且密文务必通过Base64编码传输以避免二进制损坏——每一步疏忽都可能导致静默失败或严重安全漏洞，堪称Java加密开发不可或缺的避坑指南。

AES加密必须指定模式和填充，否则会抛异常

Java的Cipher类不会给你默认的“安全配置”，不显式指定"AES/ECB/PKCS5Padding"这类完整转换字符串，运行时直接报java.security.NoSuchAlgorithmException或InvalidAlgorithmParameterException。ECB模式虽然能跑通，但**绝对不能用于生产**——相同明文块永远生成相同密文块，攻击者能靠统计分析还原结构。

• 务必用Cipher.getInstance("AES/CBC/PKCS5Padding")或"AES/GCM/NoPadding"（GCM自带认证，推荐）
• CBC模式必须传IvParameterSpec，且每次加密用新IV（可随机生成后与密文一起存储）
• GCM模式要求iv长度为12字节，tagLength通常设为128位（即16字节），少于这个值会抛InvalidAlgorithmParameterException

密钥长度不是随便填数字，得严格匹配AES-128/192/256

Java默认JRE支持AES-128，但AES-256需要JCE Unlimited Strength策略文件（JDK 8u161+已内置，旧版本需手动替换$JAVA_HOME/jre/lib/security下的local_policy.jar）。用错长度会触发InvalidKeyException: Illegal key size。

• 128位密钥 = 16字节byte数组，对应SecretKeySpec(keyBytes, "AES")
• 别用String.getBytes()直接转密钥字符串——编码不可控，应使用MessageDigest或SecretKeyFactory派生（如PBKDF2WithHmacSHA256）
• 硬编码密钥字符串如"my16byteslongkey!"看似16字符，但UTF-8下可能不是16字节（含中文或emoji就崩）

Cipher.init()的opmode参数写反会导致解密失败但无提示

加密用Cipher.ENCRYPT_MODE，解密用Cipher.DECRYPT_MODE，这两个常量值是整数（1和2），写反了不会编译报错，但解密时输出乱码或BadPaddingException，尤其在CBC/GCM模式下更难定位。

• 检查cipher.init()第二参数是否和业务逻辑一致：加密流程里不能出现DECRYPT_MODE
• GCM模式解密前必须先调用cipher.updateAAD()传入附加认证数据（AAD），漏掉这步也会导致AEADBadTagException
• 同一个Cipher实例不能复用加密/解密状态，每次操作前必须重新init()

Base64编码不是可选项，是跨系统传输密文的必要环节

原始AES密文是二进制字节数组，直接转String会因平台默认编码（如Windows-1252）损坏数据，后续解密必然失败。错误现象常是javax.crypto.BadPaddingException: Given final block not properly padded，其实根本原因是字节流被篡改过。

• 加密后立刻用Base64.getEncoder().encodeToString(cipher.doFinal(plainBytes))
• 解密前先用Base64.getDecoder().decode(encodedCipherText)还原字节数组
• 别用new String(bytes)或String.getBytes()在密文上做任何操作——它们不是为二进制设计的

GCM模式的doFinal()会自动追加认证标签，但如果你手动截断或拼接字节数组，标签校验就失效了；这种问题往往只在特定输入长度下暴露，很难复现。

好了，本文到此结束，带大家了解了《Java对称加密实战：AES与Cipher配置详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！