Bug ID: JDK-8201633 Problems with AES-GCM native acceleration

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 12	JDK 13	JDK 8	Other
11.0.2Fixed	12.0.2Fixed	13 b08Fixed	8u261Fixed	openjdk8u272Fixed

A DESCRIPTION OF THE PROBLEM :
1. Encrypting large data buffers, using only cipher.doFinal(buffer) call is slow. Hardware acceleration kicks in only after encrypting multiple buffers in a loop.
2. Splitting encryption into many cipher.update calls, followed by cipher.doFinal, triggers the acceleration almost immediately. Should be done automatically inside a single cipher.doFinal(chunk) call (see 1.)
3. Most significant problem: Splitting DEcryption into many cipher.update calls, followed by cipher.doFinal, does not trigger the acceleration. Hardware acceleration kicks in only after encrypting multiple buffers in a loop. Meaning that decryption of gigabytes of data cannot be accelerated by AES-NI hardware.

See https://stackoverflow.com/questions/48905291/java-9-aes-gcm-performance
(same is true for Java 10). Feel free to contact me for additional details.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
https://stackoverflow.com/questions/48905291/java-9-aes-gcm-performance
(same is true for Java 10). 


---------- BEGIN SOURCE ----------
https://stackoverflow.com/questions/48905291/java-9-aes-gcm-performance
(same is true for Java 10). 
---------- END SOURCE ----------

As with 11u, the 8u fix needs to be pushed together with JDK-8220165.
30-07-2020
Fix Request (8u) Same reason as for 11u, plus keeping codebases in sync (I see 8u261). Patch applies to 8u with minor fuzz. It passes jdk_security and tier1 tests. Performance improvement is confirmed: https://cr.openjdk.java.net/~shade/8201633/perf-8u.txt
30-07-2020
If we backport this patch to 11u we also need https://bugs.openjdk.java.net/browse/JDK-8220165.
08-03-2019
Fix Request Backporting this patch resolves the AES-GCM performance pothole with very slow warmup on large blocks, and it also improves throughput on smaller blocks. Patch applies cleanly to 11u after JDK-8179098 is backported. It passes jdk_security and tier1 tests. Performance improvement is confirmed: http://cr.openjdk.java.net/~shade/8201633/perf.txt
27-02-2019
Note for backporting: this requires JDK-8179098 to be applied first.
27-02-2019
Fix Request Performance fix reported by various enterprises. Very slow bottleneck when intrinsics fails to cut in.
12-02-2019
one patch option discussed via http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018951.html
30-01-2019
Current AES GCM code may have to be re-factored to address #3 as the decryption does not really kick in until the tag is given which is at the end of data stream. This is due to the spec restriction of not returning recovered data before successful tag verification. Thus, for decryption, the update() calls merely store the supplied cipher data and that's probably why the native acceleration isn't triggered until doFinal() call is made.
24-04-2018

Duplicate :	JDK-8218028 - Problems with AES-GCM native acceleration
Relates :	JDK-8220165 - Encryption using GCM results in RuntimeException: input length out of bound
Relates :	JDK-8179098 - Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)