JDK-8201633 : Problems with AES-GCM native acceleration
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 10,11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2018-04-12
  • Updated: 2019-05-16
  • Resolved: 2019-02-11
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
11.0.2Fixed 12.0.2Fixed 13 b08Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
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 ----------


Comments
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