1

One of our customers has migrated from IBM J9 (Java 8)

IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160427_301573 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160427_1620_B301573
JIT  - tr.r14.java.green_20160329_114288
GC   - R28_Java8_SR3_20160427_1620_B301573_CMPRSS
J9CL - 20160427_301573)
JCL - 20160421_01 based on Oracle jdk8u91-b14

to Java 11

openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9-LTS, mixed mode, sharing)

they have changed security provider from com.ibm.crypto.provider to sun.security.provider, and they have noticed a performance issue in a signing JWT functionality, in JDK11 most of the time is spent in MD5 class, the bad news is IBM JDK has deprecated and disabled MD5, second news is MD5 on java is just slow, it's written in java. We've downloaded and inspected MD5 implementation of IBM JDK and it's full of native calls, binary shifts and intrinsic code, then we found in the Javadoc for that class and it simply says:

This is done via a hardware crypto call.

OpenJDK uses Java code to produce MD5 hashes, when IBM uses some kind of CPU cryptographic modules. I can't find any good benchmarks for MD5 in Sun, IBM or bouncycastle implementation. Any idea if this is also solved via hardware in OpenJ9?

Thanks in advance

Torres
  • 5,330
  • 4
  • 26
  • 26

1 Answers1

1

We have released a package that improved this - Use AmazonCorrettoCryptoProvider for general crypto enhancements.

https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/

The project is on - https://github.com/corretto/amazon-corretto-crypto-provider

Feedback/Comparison of results, would be really appreciated. Crypto implementations in Java continue to evolve.

Yishai Galatzer
  • 8,791
  • 2
  • 32
  • 41