WebSphere Application Server & Liberty

 View Only

Better Java Cryptography Performance

By TIM PICKETT posted Mon October 25, 2021 11:14 AM


Better Java Cryptography Performance


Encryption is a crucial security aspect of any WebSphere Application Server(WAS) environment.  Simply configuring the encryption within your application server will undoubtedly impact your throughput performance.  In this blog we’ll discuss configuration options which will minimize this impact while keeping your server as secure as possible.


When you initially configure your application server to run with encryption security, either WAS Traditional or Liberty, by default they will use IBMJCE(Java Cryptography Extensions) and IBMJCEFIPS java cryptographic extension providers.  While these defaults are heavily used and have been tested for a long time on a variety of scenarios, their performance is not all that great.  A better performing choice is to use IBMJCEPlus and IBMJCEPlusFIPS providers when available.

The IBMJCEPlus and IBMJCEPlusFIPS cryptographic providers are implementations of the Java Cryptography Extensions JCE APIs, which include, for example: ciphers, signatures, message digests, MACs and HMACs, secure random number generation, and key generation.  The IBMJCEPlusFIPS provider provides cryptographic functions that have been FIPS certified, these are commonly used to enable FIPS(Federal Information Processing Standards) certified TLS communications. These providers are based on an existing IBM component GSKit which is based on OpenSSL.  The crypto algorithms are very well tuned across platforms which is why they outperform the default providers.  TLS 1.3(Transport Layer Security) is also supported and accelerated by these providers.  It is worth noting that not all providers are implemented in IBMJCEPlus, but improvements are being made all the time.  IBMJCEPlus is supported on Linux (amd64, POWER and Z) , AIX, Windows and z/OS in IBM SDK for Java8.

The following chart offers a comparison of an EE7 application running on Linux amd64.

The chart above shows the performance overhead configuring TLS overhead as compared to the baseline where TLS was not configured.  The performance overhead has reduced from 56% to just 7% by switching from the IBMJCE default provider to the IBMJCEPlus provider. These results use TLSv1.2 https.cipherSuites set to TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.  Results could vary when selecting other cipher suites to use.

Below are similar charts showing the overhead on other platforms. 

The IBMJCE on Linux on Z has had optimizations added over the years so the difference between IBMJCEPlus and IBMJCE on Linux on Z is minimal.

How to configure IBMJCEPlus

The procedure to configure java8 to use IBMJCEPlus is straightforward.  By editing the java.security file in JAVA_HOME/jre/lib/security directory, you simply add the IBMJCEPlus provider to the list of providers in that file. The number in the list is the priority number.  The lower the number, the higher the priority. JCE algorithms are searched from the JCE providers list in decreasing order of priority.  The resulting list would look like this:





If you need to use IBMJCEPlusFIPS, replace security.provider.3 with the following:



As you can see the use of IBMJCEPlus and IBMJCEPlusFIPS providers is highly advantageous to reaching optimal throughput performance of your application.  Beyond that the setup is quite simple and new improvements are being developed and released in an ongoing basis.  We highly encourage users to try it out in their performance test environment to understand the improvements you’ll expect to see in production.  While IBMJCEPlus is not the default provider at the time of publishing this blog, stay tuned as a change to the default could occur in the future.  Either way, older Java8 installations would still need the changes described here in this blog.




UPDATE (November 2021)

Starting with Java 8 service refresh 7 (November 2021), IBMJCEPlus provider is the default security provider on AIX®, Linux, and Windows, therefore no additional configuration changes are needed.

This link describes more details regarding the default security provider change.