jdk 加密_使用JDK的密码流的加密怪癖（以及该怎么做）

雨点打透心脏的1/2处 2023-02-25 03:51 31阅读 0赞

jdk 加密

在我们的日常工作中，我们经常遇到经常性的主题，即将数据（例如文件）从一个位置传输到另一个位置。 这听起来像是一个非常简单的任务，但让我们通过声明这些文件可能包含机密信息并可以通过非安全的通信渠道进行传输这一事实，使其变得更加困难。

首先想到的解决方案之一是使用加密算法。 由于文件可能真的很大，可能是数百兆或数十千兆字节，因此使用像[AES][]这样的对称加密方案可能很有意义。 除了仅加密外，还要确保数据在传输过程中不会被篡改。 幸运的是，有一种叫做[认证加密][Link 1]的东西，它同时为我们提供了机密性，完整性和真实性保证。 [Galois / Counter Mode][Galois _ Counter Mode] （ [GCM][Galois _ Counter Mode] ）是最流行的模式之一，支持[身份验证加密][Link 1] ，可以与[AES][]一起使用。 这些想法使我们使用了足够强大的加密方案**AES256-GCM128** 。

如果您使用的是JVM平台，则应该感到幸运，因为[Java加密体系结构][Java] （ [JCA][Java] ）支持[AES][]和[GCM][Galois _ Counter Mode] 。 话虽这么说，让我们看看我们能走多远。

我们要做的第一件事是生成一个新的**AES256**密钥。 与往常一样， [OWASP][]对于正确使用[JCA][Java] / [JCE][] API [提出][Link 2]了[许多建议][Link 2] 。

final SecureRandom secureRandom = new SecureRandom();          final byte [] key = new byte [ 32 ];  secureRandom.nextBytes(key);  final SecretKey secretKey = new SecretKeySpec(key, "AES" );

另外，要初始化[AES][] / [GCM][Galois _ Counter Mode]密码，我们需要生成随机初始化向量（或简称为IV）。 根据[NIST的][NIST]建议，其长度应为**12个字节** （96位）。

*对于IV，建议实现将支持范围限制为96位，以提高互操作性，效率和设计的简便性。* *–*   
 *[块密码模式的建议：伽罗瓦/计数器模式（GCM）和GMAC][GCM_GMAC]*

所以我们在这里：

final byte [] iv = new byte [ 12 ];  secureRandom.nextBytes(iv);

准备好[AES][]密钥和IV后，我们可以创建一个密码实例并实际执行加密部分。 处理大文件假定依赖于流，因此我们将**BufferedInputStream** / **BufferedOutputStream**与**CipherOutputStream**结合使用进行加密。

public static void encrypt(SecretKey secretKey, byte [] iv, final File input, 
             final File output) throws Throwable { 
         final Cipher cipher = Cipher.getInstance( "AES/GCM/NoPadding" ); 
         final GCMParameterSpec parameterSpec = new GCMParameterSpec( 128 , iv); 
         cipher.init(Cipher.ENCRYPT_MODE, secretKey, parameterSpec); 
         try ( final BufferedInputStream in = new BufferedInputStream( new FileInputStream(input))) { 
             try ( final BufferedOutputStream out = new BufferedOutputStream( new CipherOutputStream( new FileOutputStream(output), cipher))) { 
                 int length = 0 ; 
                 byte [] bytes = new byte [ 16 * 1024 ]; 
                 while ((length = in.read(bytes)) != - 1 ) { 
                     out.write(bytes, 0 , length); 
                 } 
             } 
         }  }

请注意，我们如何指定标签大小为**128位的** [GCM][Galois _ Counter Mode]密码参数，并以加密模式对其进行初始化（在处理64Gb以上的文件时，请[注意某些GCM限制][GCM] ）。 除了在解密模式下初始化密码之外，解密部分没有什么不同。

public static void decrypt(SecretKey secretKey, byte [] iv, final File input, 
             final File output) throws Throwable { 
         final Cipher cipher = Cipher.getInstance( "AES/GCM/NoPadding" ); 
         final GCMParameterSpec parameterSpec = new GCMParameterSpec( 128 , iv); 
         cipher.init(Cipher.DECRYPT_MODE, secretKey, parameterSpec);         
         try (BufferedInputStream in = new BufferedInputStream( new CipherInputStream( new FileInputStream(input), cipher))) { 
             try (BufferedOutputStream out = new BufferedOutputStream( new FileOutputStream(output))) { 
                 int length = 0 ; 
                 byte [] bytes = new byte [ 16 * 1024 ];                 
                 while ((length = in.read(bytes)) != - 1 ) { 
                     out.write(bytes, 0 , length); 
                 } 
             } 
         }  }

看来我们完成了，对吧？ 不幸的是，实际上，对小文件进行加密和解密仅需片刻，但处理或多或少的实际数据样本却会产生令人震惊的结果。

![format_png][]

处理一个〜42Mb文件通常需要8分钟（您可能会猜到，文件越大，花费的时间越长），快速分析显示，大部分时间都是在解密数据时花费的（请注意，这绝不是基准，仅是测试）。 在[这里][Link 3] ， [这里][Link 4] ， [这里][Link 5]和[这里][Link 6] ，寻找可能的罪魁祸首指出了[JCA][Java]实现中[AES][] / [GCM][Galois _ Counter Mode]和**CipherInputStream** / **CipherOutputStream**的长期问题清单。

那么有什么选择呢？ 似乎有可能牺牲**CipherInputStream** / **CipherOutputStream** ，重构实现以直接使用密码，并使用[JCA][Java]原语使加密/解密工作。 但是可以说，引入经过战斗测试的[BouncyCastle][]库是更好的方法。

从实现的角度来看，解决方案看起来几乎是相同的。 确实，尽管命名约定没有改变，但下面的代码片段中的**CipherOutputStream** / **CipherInputStream**来自[BouncyCastle][] 。

public static void encrypt(SecretKey secretKey, byte [] iv, final File input, 
             final File output) throws Throwable { 
         final GCMBlockCipher cipher = new GCMBlockCipher( new AESEngine()); 
         cipher.init( true , new AEADParameters( new KeyParameter(secretKey.getEncoded()), 128 , iv)); 
         try (BufferedInputStream in = new BufferedInputStream( new FileInputStream(input))) { 
             try (BufferedOutputStream out = new BufferedOutputStream( new CipherOutputStream( new FileOutputStream(output), cipher))) { 
                 int length = 0 ; 
                 byte [] bytes = new byte [ 16 * 1024 ]; 
                 while ((length = in.read(bytes)) != - 1 ) { 
                     out.write(bytes, 0 , length); 
                 } 
             } 
         }  }  public static void decrypt(SecretKey secretKey, byte [] iv, final File input, 
             final File output) throws Throwable { 
         final GCMBlockCipher cipher = new GCMBlockCipher( new AESEngine()); 
         cipher.init( false , new AEADParameters( new KeyParameter(secretKey.getEncoded()), 128 , iv)); 
         try (BufferedInputStream in = new BufferedInputStream( new CipherInputStream( new FileInputStream(input), cipher))) { 
             try (BufferedOutputStream out = new BufferedOutputStream( new FileOutputStream(output))) { 
                 int length = 0 ; 
                 byte [] bytes = new byte [ 16 * 1024 ];                 
                 while ((length = in.read(bytes)) != - 1 ) { 
                     out.write(bytes, 0 , length); 
                 } 
             } 
         }  }

使用[BouncyCastle][]加密原语重新运行以前的加密/解密测试会产生完全不同的画面。

![format_png 1][]

公平地说，JVM平台上的文件加密/解密最初看起来像是一个已解决的问题，但事实证明它充满了令人惊讶的发现。 尽管如此，由于[BouncyCastle的存在][BouncyCastle] ， [JCA][Java]实施的一些缺陷[得以][BouncyCastle]有效，简洁地解决。

请在[Github][]上找到完整的资源。

> 翻译自: [https://www.javacodegeeks.com/2020/05/the-crypto-quirks-using-jdks-cipher-streams-and-what-to-do-about-that.html][https_www.javacodegeeks.com_2020_05_the-crypto-quirks-using-jdks-cipher-streams-and-what-to-do-about-that.html]

jdk 加密

[AES]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[Link 1]: https://en.wikipedia.org/wiki/Authenticated_encryption
[Galois _ Counter Mode]: https://en.wikipedia.org/wiki/Galois/Counter_Mode
[Java]: https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html
[OWASP]: https://owasp.org
[JCE]: https://en.wikipedia.org/wiki/Java_Cryptography_Extension
[Link 2]: https://owasp.org/www-community/Using_the_Java_Cryptographic_Extensions
[NIST]: https://www.nist.gov/
[GCM_GMAC]: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf
[GCM]: https://crypto.stackexchange.com/questions/31793/plain-text-size-limits-for-aes-gcm-mode-just-64gb
[format_png]: /images/20230209/350828db779a4ec7ae254ee71ddef3d8.png
[Link 3]: https://bugs.openjdk.java.net/browse/JDK-8201633
[Link 4]: https://stackoverflow.com/questions/60575897/cipherinputstream-hangs-while-reading-data
[Link 5]: https://crypto.stackexchange.com/questions/20333/encryption-of-big-files-in-java-with-aes-gcm
[Link 6]: https://stackoverflow.com/questions/26920906/how-come-putting-the-gcm-authentication-tag-at-the-end-of-a-cipher-stream-require-internal-buffering-
[BouncyCastle]: https://www.bouncycastle.org/
[format_png 1]: /images/20230209/96333285a7e848f1a063ba0853a29b78.png
[Github]: https://github.com/reta/aes-gcm-jdk-vs-bouncycastle
[https_www.javacodegeeks.com_2020_05_the-crypto-quirks-using-jdks-cipher-streams-and-what-to-do-about-that.html]: https://www.javacodegeeks.com/2020/05/the-crypto-quirks-using-jdks-cipher-streams-and-what-to-do-about-that.html