重庆做网站哪家好,河南郑州解封通知,seo排名的方法,商城网站建设报价表在我们的日常工作中#xff0c;我们经常遇到经常性的主题#xff0c;即将数据#xff08;例如文件#xff09;从一个位置传输到另一个位置。 这听起来像是一个非常简单的任务#xff0c;但让我们通过声明这些文件可能包含机密信息并可以通过非安全的通信渠道进行传输这一事… 在我们的日常工作中我们经常遇到经常性的主题即将数据例如文件从一个位置传输到另一个位置。 这听起来像是一个非常简单的任务但让我们通过声明这些文件可能包含机密信息并可以通过非安全的通信渠道进行传输这一事实使其变得更加困难。 首先想到的解决方案之一是使用加密算法。 由于文件可能真的很大可能是数百兆或数十千兆字节所以使用像AES这样的对称加密方案可能很有意义。 除了仅加密外确保数据在传输过程中不被篡改也将是一件很棒的事情。 幸运的是有一种叫做认证加密的东西它同时为我们提供了机密性完整性和真实性保证。 Galois /计数器模式 GCM 是最流行的模式之一支持身份验证加密 可以与AES一起使用。 这些想法使我们使用了足够强大的加密方案AES256-GCM128 。 如果您使用的是JVM平台则应该感到幸运因为Java密码体系结构 JCA 支持AES和GCM 。 话虽这么说让我们看看我们能走多远。 我们要做的第一件事是生成一个新的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 / 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密码参数并以加密模式对其进行初始化在处理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 / GCM和CipherInputStream / 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
