22

我正在尝试使用 AES/GCM/NoPadding 加密和解密数据。我安装了 JCE Unlimited Strength Policy Files 并运行了下面的(简单的)基准测试。我使用 OpenSSL 完成了相同的操作,并且能够在我的 PC 上实现超过1 GB/s 的加密和解密。

通过下面的基准测试,我只能在同一台 PC 上使用 Java 8获得3 MB/s 的加密和解密。知道我做错了什么吗?

public static void main(String[] args) throws Exception {
    final byte[] data = new byte[64 * 1024];
    final byte[] encrypted = new byte[64 * 1024];
    final byte[] key = new byte[32];
    final byte[] iv = new byte[12];
    final Random random = new Random(1);
    random.nextBytes(data);
    random.nextBytes(key);
    random.nextBytes(iv);

    System.out.println("Benchmarking AES-256 GCM encryption for 10 seconds");
    long javaEncryptInputBytes = 0;
    long javaEncryptStartTime = System.currentTimeMillis();
    final Cipher javaAES256 = Cipher.getInstance("AES/GCM/NoPadding");
    byte[] tag = new byte[16];
    long encryptInitTime = 0L;
    long encryptUpdate1Time = 0L;
    long encryptDoFinalTime = 0L;
    while (System.currentTimeMillis() - javaEncryptStartTime < 10000) {
        random.nextBytes(iv);
        long n1 = System.nanoTime();
        javaAES256.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"), new GCMParameterSpec(16 * Byte.SIZE, iv));
        long n2 = System.nanoTime();
        javaAES256.update(data, 0, data.length, encrypted, 0);
        long n3 = System.nanoTime();
        javaAES256.doFinal(tag, 0);
        long n4 = System.nanoTime();
        javaEncryptInputBytes += data.length;

        encryptInitTime = n2 - n1;
        encryptUpdate1Time = n3 - n2;
        encryptDoFinalTime = n4 - n3;
    }
    long javaEncryptEndTime = System.currentTimeMillis();
    System.out.println("Time init (ns): "     + encryptInitTime);
    System.out.println("Time update (ns): "   + encryptUpdate1Time);
    System.out.println("Time do final (ns): " + encryptDoFinalTime);
    System.out.println("Java calculated at " + (javaEncryptInputBytes / 1024 / 1024 / ((javaEncryptEndTime - javaEncryptStartTime) / 1000)) + " MB/s");

    System.out.println("Benchmarking AES-256 GCM decryption for 10 seconds");
    long javaDecryptInputBytes = 0;
    long javaDecryptStartTime = System.currentTimeMillis();
    final GCMParameterSpec gcmParameterSpec = new GCMParameterSpec(16 * Byte.SIZE, iv);
    final SecretKeySpec keySpec = new SecretKeySpec(key, "AES");
    long decryptInitTime = 0L;
    long decryptUpdate1Time = 0L;
    long decryptUpdate2Time = 0L;
    long decryptDoFinalTime = 0L;
    while (System.currentTimeMillis() - javaDecryptStartTime < 10000) {
        long n1 = System.nanoTime();
        javaAES256.init(Cipher.DECRYPT_MODE, keySpec, gcmParameterSpec);
        long n2 = System.nanoTime();
        int offset = javaAES256.update(encrypted, 0, encrypted.length, data, 0);
        long n3 = System.nanoTime();
        javaAES256.update(tag, 0, tag.length, data, offset);
        long n4 = System.nanoTime();
        javaAES256.doFinal(data, offset);
        long n5 = System.nanoTime();
        javaDecryptInputBytes += data.length;

        decryptInitTime += n2 - n1;
        decryptUpdate1Time += n3 - n2;
        decryptUpdate2Time += n4 - n3;
        decryptDoFinalTime += n5 - n4;
    }
    long javaDecryptEndTime = System.currentTimeMillis();
    System.out.println("Time init (ns): " + decryptInitTime);
    System.out.println("Time update 1 (ns): " + decryptUpdate1Time);
    System.out.println("Time update 2 (ns): " + decryptUpdate2Time);
    System.out.println("Time do final (ns): " + decryptDoFinalTime);
    System.out.println("Total bytes processed: " + javaDecryptInputBytes);
    System.out.println("Java calculated at " + (javaDecryptInputBytes / 1024 / 1024 / ((javaDecryptEndTime - javaDecryptStartTime) / 1000)) + " MB/s");
}

编辑: 我把它作为一个有趣的练习来改进这个简单的基准。

我已经使用 ServerVM 进行了更多测试,删除了 nanoTime 调用并引入了预热,但正如我预期的那样,这些都没有对基准测试结果有任何改进。它是扁平的,每秒3兆字节。

4

3 回答 3

20

抛开微基准测试不谈,JDK 8(至少高达 1.8.0_25)中的 GCM 实现的性能被削弱了。

我可以通过更成熟的微基准测试始终如一地重现 3MB/s(在 Haswell i7 笔记本电脑上)。

代码潜水来看,这似乎是由于简单的乘法器实现和 GCM 计算没有硬件加速。

相比之下,JDK 8 中的 AES(ECB 或 CBC 模式)使用 AES-NI 加速内在函数,并且(至少对于 Java)非常快(在同一硬件上大约 1GB/s),但整体 AES/GCM性能完全由破碎的 GCM 性能主导。

计划实施硬件加速,并且已经有第三方提交来提高性能,但这些还没有发布。

需要注意的其他一点是,JDK GCM 实现还在解密时缓冲整个明文,直到验证密文末尾的身份验证标签,这会削弱它用于大消息的能力。

Bouncy Castle(在撰写本文时)具有更快的 GCM 实现(如果您正在编写不受软件专利法约束的开源软件,还有 OCB)。


2015 年 7 月更新 - 1.8.0_45 和 JDK 9

JDK 8+ 将获得改进的(和恒定时间的)Java 实现(由 RedHat 的 Florian Weimer 提供)——这已在 JDK 9 EA 构建中登陆,但显然还没有在 1.8.0_45 中。JDK9(至少从 EA b72 开始)也具有 GCM 内在函数 - b72 上的 AES/GCM 速度为 18MB/s (未启用内在函数)和 25MB/s (启用内在函数),两者都令人失望 - 用于比较最快(非恒定时间)BC实现速度约为 60MB/s,最慢的(恒定时间,未完全优化)约为 26MB/s。


2016 年 1 月更新 - 1.8.0_72:

JDK 1.8.0_60中出现了一些性能修复,现在在同一基准上的性能为 18MB/s - 比原来的性能提高了 6 倍,但仍然比 BC 实现慢得多。

于 2014-11-19T22:13:26.203 回答
4

现在已经在 J​​ava 8u60 中通过JDK-8069072部分解决了这个问题。如果没有这个修复,我会得到 2.5M/s。通过此修复,我得到 25M/s。完全禁用 GCM 给我 60M/s。

要完全禁用 GCM,请创建一个java.security使用以下行命名的文件:

jdk.tls.disabledAlgorithms=SSLv3,GCM

然后使用以下命令启动您的 Java 进程:

java -Djava.security.properties=/path/to/my/java.security ...

如果这不起作用,您可能需要通过编辑启用覆盖安全属性/usr/java/default/jre/lib/security/java.security(实际路径可能因操作系统而异)并添加:

policy.allowSystemProperty=true
于 2015-08-31T19:03:00.007 回答
0

OpenSSL 实现由汇编例程使用 pclmulqdq 指令(x86 平台)进行优化。由于并行算法,它非常快。

java实现很慢。但它也在 Hotspot 中使用汇编程序(非并行)进行了优化。您必须预热 jvm 才能使用 Hotspot 内在函数。-XX:CompileThreshold 的默认值为 10000。

// 伪代码

warmUp_GCM_cipher_loop10000_times();

做基准();

于 2016-01-27T07:13:30.223 回答