使用JDK的密码流的加密怪癖(以及如何做)

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

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

如果您使用的是JVM平台,则应该感到幸运,因为Java密码体系结构JCA )支持AESGCM 。 话虽这么说,让我们看看我们能走多远。

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

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

另外,要初始化AES / GCM密码,我们需要生成随机初始化向量(或简称为IV)。 根据NIST的建议,其长度应为12个字节 (96位)。


对于IV,建议实现将支持范围限制为96位,以提高互操作性,效率和设计的简便性。
针对块密码模式的建议:伽罗瓦/计数器模式(GCM)和GMAC

所以我们在这里:

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

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

 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密码参数,并以加密模式对其进行初始化(在处理64Gb以上的文件时要注意一些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); 
             } 
         } 
     }  } 

看来我们完成了,对吧? 不幸的是,实际上,对小文件进行加密和解密只需要花费一点时间,但是处理或多或少的实际数据样本却会产生令人震惊的结果。

处理一个〜42Mb文件通常需要8分钟(您可能会猜到,文件越大,花费的时间就越长),快速分析显示,大部分时间都是在解密数据时花费的(请注意,这绝不是基准,仅是测试)。 在这里这里这里这里 ,寻找可能的罪魁祸首指出了JCA实现中AES / GCMCipherInputStream / CipherOutputStream的长期问题清单。

那么还有哪些选择呢? 似乎有可能牺牲CipherInputStream / CipherOutputStream ,重构实现以直接使用密码,并使用JCA原语使加密/解密工作。 但是可以说,引入经过战斗测试的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加密原语重新运行之前的加密/解密测试会产生完全不同的画面。

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值