【问题标题】:Java AES/CBC/PKCS5Padding stream encryption performance compared to no encryptionJava AES/CBC/PKCS5Padding 流加密性能对比不加密
【发布时间】:2016-11-27 06:08:04
【问题描述】:

我正在使用使用 RSA 密钥/对的标准技术,其公钥加密一个 16 字节随机密钥,该密钥使用 AES/CBC/PKCS5Padding 加密我的数据。 我正在使用充气城堡来满足我的需要我需要加密通常是大数据流 (512MB+)。 在运行性能测试以了解加密的开销时,我发现加密比未加密的数据贵近 30-40%。 这是预期的吗?

示例代码

public InputStream encryptStream(InputStream streamToEncrypt, byte[] key, byte[] iv, byte[] encryptedKey // 256 bytes) {

        final Cipher cipher = getCipher(Cipher.ENCRYPT_MODE, key, iv);
        byte[] civ = cipher.getIV();
         ...
        ByteArrayInputStream ivEncryptedKeyStream = new ByteArrayInputStream(ivEncryptedKeyArray);
        CipherInputStream encrypted = new CipherInputStream(streamToEncrypt, cipher);

        return new SequenceInputStream(ivEncryptedKeyStream, encrypted);
    }

别处

 InputStream encryptedStream = ...encryptStream(plainStream, key, iv, encKey);
 IOUtils.copyLarge(encryptedStream, outputStream);

我玩过 java server args ;确认 AES-NI 指令集已开启等。 只是想知道加密大型流的开销是多少?

编辑:更正了我仅将 bouncycastle 用于密钥对生成的信息。对于使用 SunJCE 作为安全提供程序的 AES 加密。

【问题讨论】:

  • 您是否检查过您的 Java 版本是否使用 AES-NI?见AES-NI intrinsics enabled by default?
  • 谢谢。我已经尝试过使用这些参数,并且还添加了 -server 参数,发现性能略有提高。我也会对此进行更多研究。

标签: java security encryption aes


【解决方案1】:

将 Bouncy Castle 用于 Oracle Java API 中已有的所有内容的想法让我无法理解。 Bouncy 不会为 Bouncy 启用 AES-NI,因为 Bouncy 是一个仅软件库。 Java 不会用硬件指令神奇地替换 AESFastEngine。如果您想提高速度,只需使用 Oracle 实现即可。

至于开销:是的,开销应该是可以预料的。与其他计算相比,百分比有多大当然取决于机器和其他计算的性能。不过,40% 可能是一个合理的预期。

注意事项:

  • 最新的 Java 版本也使用 CPU 指令进行 BigInteger 操作,因此这也可能加快 RSA 操作;
  • 对 Java 和/或 AES CBC 使用 PKCS#1 填充会使您的密文容易受到填充 oracle 攻击(如果这些攻击适用,例如在传输协议中);
  • 请确保使用足够大的测试集,JIT 编译和优化可能会相对较晚。

【讨论】:

  • 感谢指出,我已更正信息。我实际上使用 Oracle Java API 来加密流。我将尝试大型测试集,但我会立即看到 10 个样本大小与 10000 个 3MB 文件之间的差异。在我对 10000 个文件的测试中,性能影响约为 30%。接下来我将尝试对更大的文件进行基准测试,但理论上更大的文件会产生更大的影响还是没关系?
  • @sunny 不,只要您不使用其他虚拟机,那么性能优势可能很小。 30 GB 似乎已经足够测试了,届时代码将被优化。密钥包装和 AES 密钥计划可能会产生一些影响,但这不太可能对您的发现产生太大影响。
  • 请注意,这是我使用优化的 C 或 C++ 例程而不是 Java 的少数几个地方之一。与本机代码相比,Java 中的加密相对较慢,即使使用内在函数也是如此。与脚本语言相比,它的速度当然快得惊人。
  • 我正在使用 jdk7。正如@Robert 指出的那样,已经尝试了 -server 和 AES 参数,但只看到了非常轻微的改进。 30-40% 似乎是一个稍大的值。显然,如果我能保证每个数据集使用不同的密钥,我有点了解使用 AES/CBC/ 有或没有填充以及使用 iv 的算法。我的目标是 7-15% 的开销。
  • 如前所述,开销是主观的。除非您对计算开销的内容有所了解,否则您无法确定开销。针对特定配置以特定 MB/s 为目标似乎更合乎逻辑。注意:您可能有多个核心和文件。这听起来像是多线程的主要目标(除非您的 IO 仍在旋转)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-11-16
  • 2018-11-28
  • 1970-01-01
  • 2014-01-13
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多