-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
11
Performance issue when decrypting large set of data with hardware AES-NI accelerator
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
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
- duplicates
-
JDK-8201633 Problems with AES-GCM native acceleration
-
- Resolved
-