当前位置： 首页 > news >正文

Java AES/CBC/PKCS5Padding 加密解密实战指南与避坑

news 2026/7/3 0:36:26

1. 项目概述：为什么AES/CBC/PKCS5Padding是Java开发者的必修课？

如果你是一名Java开发者，无论是做后端服务、Android应用，还是处理一些需要数据安全的桌面工具，加密和解密几乎是一个绕不开的话题。我见过太多项目，把用户密码明文存数据库，把配置文件里的敏感信息直接暴露，甚至API传输的数据也毫无保护。等到出了事，数据泄露了，再来补救，成本就太高了。所以，掌握一套可靠、标准的加密实现，不是“加分项”，而是“基本功”。

在众多加密方案里，AES（高级加密标准）无疑是当前应用最广泛的对称加密算法。它安全、高效，被全球的金融、政府和互联网公司所信赖。而CBC（密码分组链接）模式，则是AES最常用、也最需要理解其特性的工作模式之一。再加上PKCS5Padding这个填充方案，就构成了一个在Java生态里极其经典的加密组合：AES/CBC/PKCS5Padding。

这个组合为什么经典？因为它平衡了安全性和实现的便利性。AES保证了加密强度，CBC模式通过引入初始化向量（IV）让相同的明文每次加密产生不同的密文，有效抵御了某些分析攻击，而PKCS5Padding则解决了AES分组加密时数据长度必须对齐的问题。但正是这个“经典”组合，也藏着不少坑。比如，IV该怎么生成和管理？密钥长度到底选128位还是256位？加解密流程中，哪个环节错了会导致整个操作失败？这些细节，官方文档不会手把手教你，但却是实战中决定成败的关键。

接下来，我就以一个老开发的身份，带你从零开始，手把手实现一个健壮的、可用于生产环境的AES/CBC/PKCS5Padding加密工具类。我们不止看代码怎么写，更要深挖每一步背后的“为什么”，并分享那些我踩过、填平的坑。

2. 核心原理与设计思路拆解

在动手写代码之前，我们必须把脑子里的概念理清楚。加密不是魔法，是一套严谨的数学和工程实践。用错了，比不用更危险。

2.1 AES算法：对称加密的基石

AES是一种对称加密算法，意思是加密和解密使用同一把密钥。它的核心操作是在一个固定大小的“块”（Block）上进行的，AES的块大小固定为128位（16字节）。无论你的密钥是128位、192位还是256位，它加密的数据单元都是16字节一块。

为什么是128位块？这是一个在安全性和性能之间权衡的结果。块太小，加密模式可能不安全；块太大，处理效率会下降。128位（16字节）是一个经过广泛验证的甜蜜点。密钥长度的选择则直接关联到破解难度。128位密钥在可预见的未来仍然是安全的，但如果你处理的是金融或极高敏感数据，使用256位密钥能提供更强的安全边际，尽管它会带来轻微的性能开销（更多的加密轮数）。

注意：在Java中，如果你安装的是标准JRE，默认可能受限于“强加密策略”文件，无法使用256位密钥。你需要从Oracle官网下载并替换JRE_HOME/lib/security/目录下的local_policy.jar和US_export_policy.jar这两个文件（即所谓的JCE无限强度管辖策略文件），或者使用OpenJDK（通常已包含无限制策略）。这是实战中第一个大坑。

2.2 CBC模式：链接起来的加密块

AES本身只能加密一个16字节的块。对于任意长度的数据，我们需要一种“模式”来将多个块组合起来。ECB（电子密码本）是最简单的模式，它直接把数据分成块，每块独立加密。但这样有个致命问题：相同的明文块会产生相同的密文块。对于一张图片，加密后可能还能看出轮廓。

CBC模式就是为了解决这个问题而生的。它的核心思想是“链接”：在加密当前明文块之前，先让它与前一个密文块进行异或（XOR）操作。对于第一个块，没有“前一个密文块”，怎么办？这就引入了初始化向量（IV）。IV是一个随机生成的、长度也是16字节的数据块，它作为第一个块的“前一个密文块”参与运算。

这样一来，即使完全相同的明文，只要IV不同，产生的整个密文就会截然不同。IV不需要保密（它通常和密文一起传输），但它必须是不可预测的，并且对于每次加密操作都应该是唯一的。通常我们使用密码学安全的随机数生成器（CSPRNG）来生成IV。

2.3 PKCS5Padding：补齐最后一块

由于AES是分组加密，它要求待加密数据的长度必须是16字节的整数倍。但我们的数据长度是任意的。填充（Padding）就是在数据的末尾添加一些额外的字节，使其长度符合要求。PKCS5Padding（在AES的16字节块场景下，等同于PKCS7Padding）是一种最常用的填充方式。

它的规则很简单：假设需要填充N个字节，那么这N个字节的值都等于N。例如，如果最后一个块还差3个字节，就填充0x03 0x03 0x03。解密时，读取密文的最后一个字节，就知道填充了多少字节，从而可以准确移除。

这里有个关键点：即使原始数据长度恰好是16字节的整数倍，也需要额外填充一个完整的16字节块（值全部为0x10）。这是为了解密时能无歧义地移除填充。如果不这么做，当解密后的数据末尾恰好有几个字节是0x01时，程序可能会误认为那是填充而将其错误移除。

2.4 整体加解密流程设计

理解了组件，我们来看串联起来的流程：

加密流程：

  1. 生成或获取一个安全的密钥（Key）。
  2. 生成一个随机的、16字节的初始化向量（IV）。
  3. 创建Cipher实例，指定算法为AES/CBC/PKCS5Padding。
  4. 用密钥和IV初始化Cipher为加密模式。
  5. 对数据进行加密，得到密文。
  6. 将IV和密文组合在一起（通常IV放在密文前面），进行传输或存储。因为IV不保密，所以可以直接拼接。

解密流程：

  1. 从组合数据中分离出IV和密文。
  2. 使用相同的密钥。
  3. 创建Cipher实例，指定算法为AES/CBC/PKCS5Padding。
  4. 用密钥和IV初始化Cipher为解密模式。
  5. 对密文进行解密。
  6. 移除PKCS5Padding填充，得到原始明文。

这个流程看似直接，但每个环节都有讲究。比如密钥管理、IV的生成方式、数据拼接的格式等，下面我们在实操中一一展开。

3. 密钥生成与管理：安全的第一道门

密钥是整个加密体系的命门。密钥泄露，一切皆休。在Java中，我们通常使用KeyGenerator或SecretKeySpec来处理AES密钥。

3.1 生成随机密钥

对于新系统，生成一个随机密钥是最佳实践。

import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import java.security.NoSuchAlgorithmException; import java.security.SecureRandom; public class KeyGenDemo { public static SecretKey generateAESKey(int keySize) throws NoSuchAlgorithmException { // 1. 获取AES密钥生成器实例 KeyGenerator keyGen = KeyGenerator.getInstance("AES"); // 2. 初始化密钥生成器，指定密钥长度和随机源 // 使用SecureRandom而不是Random，后者是密码学不安全的 SecureRandom secureRandom = new SecureRandom(); keyGen.init(keySize, secureRandom); // 3. 生成密钥 return keyGen.generateKey(); } public static void main(String[] args) throws NoSuchAlgorithmException { SecretKey secretKey = generateAESKey(256); // 生成256位密钥 byte[] rawKeyData = secretKey.getEncoded(); // 获取密钥的字节数组形式 System.out.println("Generated Key (Base64): " + Base64.getEncoder().encodeToString(rawKeyData)); // 重要：这个rawKeyData需要被安全地存储，例如放入密钥管理系统或硬件安全模块(HSM) } }

关键点解析：

  • KeyGenerator.getInstance("AES")：这里传入的字符串“AES”是算法名。生成器会根据JCE提供者生成对应算法的密钥。
  • keyGen.init(keySize, secureRandom)：keySize只能是128、192或256。SecureRandom是密码学安全的随机数生成器，绝对不要用java.util.Random，它的输出是可预测的。
  • secretKey.getEncoded()：获取的是密钥的原始字节。你可以用Base64编码后打印或存储，但切记，打印或日志记录密钥是严重的安全事故。生产环境中，密钥必须存储在安全的地方，如经过加密的配置文件、密钥管理服务（KMS）或硬件安全模块中。

3.2 从固定字节数组还原密钥

更多时候，我们需要将一个事先约定好的、或从安全存储中读取的密钥字节数组，还原成SecretKey对象用于加解密。这时要用到SecretKeySpec。

import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class KeyLoadDemo { public static SecretKey loadAESKeyFromBase64(String base64Key) { byte[] keyBytes = Base64.getDecoder().decode(base64Key); // 使用SecretKeySpec构造密钥。第二个参数是算法名“AES”。 return new SecretKeySpec(keyBytes, "AES"); } public static SecretKey loadAESKeyFromBytes(byte[] keyBytes) { // 直接通过字节数组构造 return new SecretKeySpec(keyBytes, "AES"); } }

实操心得：

  • 密钥长度验证：在构造SecretKeySpec之前，最好验证一下keyBytes的长度。对于AES，它必须是16字节（128位）、24字节（192位）或32字节（256位）。如果不是，SecretKeySpec不会立即报错，但在初始化Cipher时会抛出InvalidKeyException。我建议主动检查：
    if (keyBytes.length != 16 && keyBytes.length != 24 && keyBytes.length != 32) { throw new IllegalArgumentException("Invalid AES key length: " + keyBytes.length + " bytes"); }
  • 密钥存储：永远不要将密钥硬编码在源代码中。至少应该放在配置文件中，并对配置文件进行访问控制。更优的做法是使用环境变量或在启动时从安全的密钥服务中动态获取。

4. 完整加解密工具类实现

下面我们实现一个完整的、考虑了异常处理和最佳实践的工具类。我们将采用一种常见的组合格式：[IV的字节][密文的字节]，其中IV固定为16字节。

import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.SecureRandom; import java.util.Base64; public class AesCbcUtil { private static final String TRANSFORMATION = "AES/CBC/PKCS5Padding"; private static final String ALGORITHM = "AES"; private static final int IV_SIZE = 16; // AES块大小，单位字节 /** * 加密 * @param plaintext 明文文本 * @param keyBase64 Base64编码的AES密钥 * @return Base64编码的字符串，格式为: Base64(IV + 密文) */ public static String encrypt(String plaintext, String keyBase64) throws Exception { return encrypt(plaintext.getBytes(StandardCharsets.UTF_8), keyBase64); } /** * 加密 * @param plaintextBytes 明文字节数组 * @param keyBase64 Base64编码的AES密钥 * @return Base64编码的字符串，格式为: Base64(IV + 密文) */ public static String encrypt(byte[] plaintextBytes, String keyBase64) throws Exception { // 1. 还原密钥 SecretKey secretKey = loadKey(keyBase64); // 2. 生成随机IV byte[] iv = new byte[IV_SIZE]; SecureRandom secureRandom = new SecureRandom(); secureRandom.nextBytes(iv); // 用安全随机数填充IV数组 IvParameterSpec ivSpec = new IvParameterSpec(iv); // 3. 初始化Cipher为加密模式 Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivSpec); // 4. 执行加密 byte[] ciphertextBytes = cipher.doFinal(plaintextBytes); // 5. 组合IV和密文 byte[] combined = new byte[iv.length + ciphertextBytes.length]; System.arraycopy(iv, 0, combined, 0, iv.length); System.arraycopy(ciphertextBytes, 0, combined, iv.length, ciphertextBytes.length); // 6. 返回Base64编码后的结果 return Base64.getEncoder().encodeToString(combined); } /** * 解密 * @param combinedBase64 Base64编码的字符串，格式为: Base64(IV + 密文) * @param keyBase64 Base64编码的AES密钥 * @return 明文文本 */ public static String decryptToString(String combinedBase64, String keyBase64) throws Exception { byte[] decryptedBytes = decrypt(combinedBase64, keyBase64); return new String(decryptedBytes, StandardCharsets.UTF_8); } /** * 解密 * @param combinedBase64 Base64编码的字符串，格式为: Base64(IV + 密文) * @param keyBase64 Base64编码的AES密钥 * @return 明文字节数组 */ public static byte[] decrypt(String combinedBase64, String keyBase64) throws Exception { // 1. 还原密钥 SecretKey secretKey = loadKey(keyBase64); // 2. Base64解码，得到IV+密文的组合字节数组 byte[] combined = Base64.getDecoder().decode(combinedBase64); // 3. 分离IV和密文 if (combined.length < IV_SIZE) { throw new IllegalArgumentException("Invalid combined data length"); } byte[] iv = new byte[IV_SIZE]; byte[] ciphertextBytes = new byte[combined.length - IV_SIZE]; System.arraycopy(combined, 0, iv, 0, IV_SIZE); System.arraycopy(combined, IV_SIZE, ciphertextBytes, 0, ciphertextBytes.length); IvParameterSpec ivSpec = new IvParameterSpec(iv); // 4. 初始化Cipher为解密模式 Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKey, ivSpec); // 5. 执行解密 return cipher.doFinal(ciphertextBytes); } /** * 从Base64字符串加载密钥 */ private static SecretKey loadKey(String keyBase64) { byte[] keyBytes = Base64.getDecoder().decode(keyBase64); // 简单验证密钥长度 if (keyBytes.length != 16 && keyBytes.length != 24 && keyBytes.length != 32) { throw new IllegalArgumentException("Invalid AES key length: " + keyBytes.length + " bytes. Must be 16, 24, or 32."); } return new SecretKeySpec(keyBytes, ALGORITHM); } // 示例用法 public static void main(String[] args) { try { // 假设这是你的密钥，实际应从安全处获取 String originalKeyBase64 = "K7A5pL2nP8cFj0HqW1eR3tY6u9iZ4X7Cv"; // 32字节的Base64编码示例 String plaintext = "这是一段需要加密的敏感数据，比如用户身份证号或交易凭证。"; System.out.println("原文: " + plaintext); // 加密 String encryptedBase64 = encrypt(plaintext, originalKeyBase64); System.out.println("加密后 (Base64): " + encryptedBase64); // 解密 String decryptedText = decryptToString(encryptedBase64, originalKeyBase64); System.out.println("解密后: " + decryptedText); System.out.println("加解密结果是否一致: " + plaintext.equals(decryptedText)); } catch (Exception e) { e.printStackTrace(); } } }

代码逐段解析与避坑指南：

  1. 常量定义：TRANSFORMATION字符串"AES/CBC/PKCS5Padding"必须一字不差。写错模式或填充方式，Cipher.getInstance()会直接抛出NoSuchAlgorithmException。

  2. IV生成：SecureRandom().nextBytes(iv)是标准做法。切勿使用固定IV，比如全零的IV。那会让CBC模式的安全优势荡然无存。IV需要是密码学安全的随机数。

  3. 数据组合：我们选择将IV直接拼在密文前面。这是一种简单通用的做法。解密时，前16字节就是IV。你也可以选择将IV用Base64单独编码，和密文的Base64用特定分隔符（如:）连接，例如Base64(IV):Base64(Ciphertext)。关键是加密和解密双方要约定好一致的格式。

  4. 异常处理：工具类方法声明了throws Exception，这是为了示例简洁。在生产代码中，你应该捕获更具体的异常，如NoSuchAlgorithmException,NoSuchPaddingException,InvalidKeyException,InvalidAlgorithmParameterException,IllegalBlockSizeException,BadPaddingException等，并根据不同异常类型进行更精细的错误处理和日志记录。BadPaddingException尤其重要，它通常意味着密钥错误、IV错误或数据在传输存储过程中被破坏。

  5. 字符编码：在encrypt(String, String)和decryptToString方法中，我们明确使用了StandardCharsets.UTF_8。这是必须的。如果不指定，会使用平台默认编码，在不同系统（如开发环境Windows和生产环境Linux）间可能导致乱码。始终在字符串和字节数组转换时指定编码。

5. 高级话题与生产环境考量

上面的工具类可以工作，但用于生产环境，还需要考虑更多。

5.1 集成Spring Boot与配置化管理

在Spring Boot项目中，你通常不会把密钥写在代码里。更佳实践是通过配置文件或配置中心管理。

  • application.yml:
    app: security: aes: key-base64: your-256bit-base64-encoded-key-here
  • 配置类与Bean:
    @Configuration public class AesConfig { @Value("${app.security.aes.key-base64}") private String aesKeyBase64; @Bean public SecretKey aesSecretKey() { // 这里可以加入更复杂的密钥加载逻辑，如从KMS获取 return AesCbcUtil.loadKeyFromConfig(aesKeyBase64); // 假设有一个加载方法 } @Bean public AesCbcUtil aesCbcUtil(SecretKey aesSecretKey) { // 可以将工具类实例化为Bean，注入密钥 return new AesCbcUtil(aesSecretKey); } }
    然后你的Service就可以@Autowired注入AesCbcUtil来使用了。这样密钥与代码分离，可以通过环境变量或配置中心动态更新。

5.2 性能优化与线程安全

Cipher对象的创建和初始化（init方法）是比较耗时的操作。在高并发场景下，频繁创建Cipher实例会成为性能瓶颈。

解决方案：使用对象池或ThreadLocal。

public class CipherPool { private static final ThreadLocal<Cipher> encryptCipherThreadLocal = ThreadLocal.withInitial(() -> { try { return Cipher.getInstance("AES/CBC/PKCS5Padding"); } catch (Exception e) { throw new RuntimeException("Failed to create Cipher instance", e); } }); // 类似地可以创建decryptCipherThreadLocal public static Cipher getEncryptCipher(SecretKey key, IvParameterSpec iv) throws Exception { Cipher cipher = encryptCipherThreadLocal.get(); cipher.init(Cipher.ENCRYPT_MODE, key, iv); return cipher; // 注意：init会重置cipher状态，所以每次使用前必须init } // 使用完毕后，通常不需要remove，线程结束时ThreadLocal会自动清理。 // 但在Web容器（如Tomcat）的线程池环境下，为了防止内存泄漏，可以在请求处理完成后调用ThreadLocal.remove()。 }

注意：Cipher对象本身不是线程安全的。ThreadLocal确保了每个线程有自己的Cipher实例，避免了并发问题。但切记，从ThreadLocal获取后，每次使用前必须调用init()方法重新初始化，因为doFinal()调用后，Cipher对象内部状态会改变，不能直接复用。

5.3 加密大数据与流式处理

如果要加密的文件或数据流非常大（比如几百MB或几个GB），一次性调用cipher.doFinal()会导致内存溢出（OOM）。

解决方案：使用分段加密/解密。Cipher类提供了update(byte[] input)和doFinal()方法组合来处理流式数据。

public static void encryptLargeFile(Path inputFile, Path outputFile, SecretKey key, IvParameterSpec iv) throws Exception { Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, key, iv); try (InputStream in = Files.newInputStream(inputFile); OutputStream out = Files.newOutputStream(outputFile); CipherOutputStream cipherOut = new CipherOutputStream(out, cipher)) { byte[] buffer = new byte[8192]; // 8KB缓冲区 int bytesRead; while ((bytesRead = in.read(buffer)) != -1) { cipherOut.write(buffer, 0, bytesRead); } } // CipherOutputStream会在close时自动调用doFinal写入最后的填充块 }

使用CipherOutputStream和CipherInputStream是处理大文件加密解密最优雅和高效的方式，它们内部帮你处理了所有的分段和填充逻辑。

6. 常见问题排查与调试技巧实录

即使代码看起来完美，在实际运行和联调中，你一定会遇到各种问题。下面是我总结的“排坑手册”。

6.1BadPaddingException: Given final block not properly padded

这是最常见的异常，没有之一。它通常不意味着你的代码有逻辑错误，而是输入的数据不对。

  • 可能原因1：密钥错误。这是最可能的情况。用于解密的密钥和加密时使用的密钥不一致。请百分百确认两端使用的密钥Base64字符串完全一致，注意是否有空格、换行符。

    • 排查：打印或日志记录两端密钥的字节长度和Base64字符串，进行比对。确保密钥加载逻辑一致。

  • 可能原因2：IV错误或数据格式错误。解密时分离IV和密文的逻辑与加密时组合的逻辑不匹配。比如加密时IV是16字节，解密时却只取了前15字节。

    • 排查：在加密后和解密前，分别打印combined数组的长度。加密后的长度应该是16 + 密文长度。密文长度由于填充，会比明文长一点。确保你的分离算法正确计算了ciphertextBytes的长度。

  • 可能原因3：数据在传输/存储过程中被破坏或编码错误。比如密文Base64字符串在传输中被URL编码/解码了一次，或者被截断，或者换行符被处理。

    • 排查：比较发送方生成的Base64字符串和接收方收到的字符串是否完全一致。对于网络传输，确保使用二进制安全的方式传递Base64字符串（如放在JSON字段中）。避免通过某些可能修改内容的文本协议传输。

  • 可能原因4：错误的算法/模式/填充字符串。加密用AES/CBC/PKCS5Padding，解密用了AES/ECB/PKCS5Padding。

    • 排查：检查两端的TRANSFORMATION字符串常量是否完全一致。

6.2InvalidKeyException: Illegal key size

尝试使用256位密钥时，如果没安装JCE无限强度管辖策略文件，就会报这个错。

  • 解决：
    1. 确认你使用的是Oracle JDK还是OpenJDK。OpenJDK 8及以上版本通常自带无限制策略。
    2. 如果是Oracle JDK，去Oracle官网下载对应版本的JCE策略文件包，解压后将其中的local_policy.jar和US_export_policy.jar复制到$JAVA_HOME/jre/lib/security/目录下，覆盖原文件（请先备份）。
    3. 一个更“工程化”的解决方法是，在项目启动脚本中检测并提示，或者强制使用128位密钥作为降级方案。

6.3 加解密结果不一致，但没报错

有时解密出来的文本大部分是对的，但末尾多了几个乱码字符，或者少了几个字符。

  • 可能原因：字符编码问题。加密时用String.getBytes()（默认平台编码），解密时用new String(bytes)（也是默认平台编码），如果两端平台编码不同（如Windows GBK vs Linux UTF-8），就会出错。
  • 解决：永远、永远、永远指定字符编码。就像我们工具类里做的，统一使用StandardCharsets.UTF_8。

6.4 如何调试？

  1. 日志记录关键中间值：在开发调试阶段，可以临时记录密钥长度、IV的Base64、加密前明文长度、加密后密文长度、组合后长度等。但切记，生产环境必须关闭这些日志，尤其是密钥和IV的日志。
  2. 单元测试：为你的工具类编写全面的单元测试，覆盖不同密钥长度、不同明文长度（特别是小于16字节、等于16字节、大于16字节）、空字符串等情况。确保每次代码修改后，基础功能依然正常。
  3. 与其它语言/平台互操作：如果你需要和PHP、Python、C#等服务进行加解密交互，确保双方使用相同的参数：
    • 算法：AES
    • 模式：CBC
    • 填充：PKCS5Padding (PKCS7)
    • 密钥长度：一致（如256位）
    • IV：随机生成，并正确传递
    • 数据格式：通常都采用IV+密文的组合，然后整体做Base64编码。
    • 字符编码：统一为UTF-8。

7. 安全性增强与最佳实践总结

最后，分享几点让加密更“坚固”的经验。

  1. 密钥生命周期管理：不要一个密钥用到永远。制定密钥轮换策略。当使用新密钥加密新数据时，旧数据可以用旧密钥解密，或者逐步迁移。密钥本身也需要加密存储（即“密钥加密密钥”的概念）。

  2. 考虑使用认证加密：CBC模式本身只提供机密性，不提供完整性校验。攻击者可能篡改IV或密文，导致解密出错误但可能有意义的数据（填充预言攻击的变种）。对于更高安全要求，可以考虑使用GCM模式（Galois/Counter Mode），它同时提供机密性、完整性和身份验证。在Java中，对应的算法字符串是AES/GCM/NoPadding。GCM模式更现代，推荐在新项目中使用。

  3. IV必须唯一且随机：我们已经强调过。对于GCM模式，这个随机值通常称为Nonce，同样要求唯一。

  4. 不要自己发明加密算法或组合：绝对不要尝试修改AES、CBC或填充的工作方式。使用经过全球密码学家多年审查的标准算法和库，如Java自带的JCE。

  5. 依赖库版本：确保你使用的Java运行环境（JRE/JDK）是得到安全支持的版本。旧版本可能存在已知的加密漏洞。

实现AES/CBC/PKCS5Padding加密是Java开发者的一项实用技能。从理解原理，到写出健壮的代码，再到处理生产环境中的各种坑，这个过程本身就是对安全编程思维的很好锻炼。记住，加密不是“加上就安全了”，密钥管理、随机数生成、数据编码、异常处理，每一个细节都关乎最终的安全性。希望这篇长文能帮你不仅写出能跑的代码，更能写出让人放心的代码。

http://www.jsqmd.com/news/1112116/

相关文章：

  • 大型网站架构系列：分布式消息队列（一）
  • 机器学习精度提升的六步工程化路径：从数据清洗到集成优化
  • 基于改进ICEEMDAN的火-混合储能协同调频控制策略研究（Matlab代码实现）
  • NVIDIA API Key 获取、管理与安全实践指南
  • 网络安全实战：从漏洞原理到内网渗透的工程师成长路径
  • IIM-42652与MK64FN1M0VDC12的6DoF运动跟踪系统设计
  • 8个Illustrator自动化脚本终极指南：彻底告别重复性设计工作
  • STM32与LV3296构建高精度实时数据采集系统
  • LV30条码扫描器与PIC18F2585嵌入式系统开发指南
  • Playnite插件开发完整指南：从零开始构建你的游戏管理神器
  • ONNX 推理优化：导出成功只是部署的第一步
  • PIC18F67K40与IS31FL3731驱动LED矩阵开发指南
  • 风控安全产品系统设计的思考与实践
  • 【Java课程设计/毕业设计】基于 SpringBoot 的免费网课学习与互动交流系统的设计与实现 数字化免费在线教育资源运维管理平台【附源码、数据库、万字文档】
  • HikariCP连接池调优全流程：80%的人都在犯的三个错，附生产级配置模板
  • 分组气泡图（Packedbubble）实战：全球车企市值分层聚合可视化
  • 告别手动抢购：Campus-iMaoTai智能茅台预约系统全攻略
  • 5分钟快速掌握Unlock Music：打破平台限制的终极音乐解锁指南
  • AD74413R与PIC18F65K40的高精度工业数据采集方案
  • 终极解决方案：如何一站式安装所有Visual C++运行库
  • 信用卡欺诈检测实战：不平衡学习与业务可解释性建模
  • 免费代理IP网站实测：5个能用的，以及一堆大实话
  • 我的小树林
  • 无人机+边缘AI驱动的自主库存感知系统
  • 网易云音乐NCM解密终极指南：5步实现音乐格式自由转换
  • 音乐文件被平台“绑架“了？3个简单方法帮你找回播放自由
  • Si4731与PIC18F85J10在无线电接收系统中的应用
  • 双新政落地｜数据分类分级如何平衡金融合规与数字金融高质量发展
  • 专业级视频质量对比工具：3大核心功能提升画质分析效率
  • 智能降重工具在学术写作中的应用与技巧