Support OpenSSL backend and implement message digest by KostasTsiounis · Pull Request #1492 · IBM/OpenJCEPlus

KostasTsiounis · 2026-05-22T20:18:34Z

With this change, all appropriate code is added to support the use of OpenSSL as a backend. That includes:

Main Java class to load the libraries required and offer native methods.
Adapter Java classes to smoothly integrate without changes with existing code.
Makefiles to compile and link required C code to use OpenSSL.
Additional test tags and general test setup to allow the execution of appropriate tests with the new backend.

Additionally, the first set of algorithms, namely the message digests, are implemented. The aforementioned tags are, also, added to the corresponding tests.

Signed-off-by: Kostas Tsiounis kostas.tsiounis@ibm.com

johnpeck-us-ibm · 2026-06-05T19:10:28Z

I know we talked about contexts and one for FIPS and one for non-FIPS. Could we use the Property query instead?
sha256 = EVP_MD_fetch(NULL, "SHA2-256", "fips=yes"); - FIPS
sha256 = EVP_MD_fetch(NULL, "SHA2-256", "provider=default"); - Non-FIPS.
Note the NULL for the context.

Does using this have any performance ramifications?

johnpeck-us-ibm · 2026-08-03T20:16:50Z

+    @SuppressWarnings("restricted")
+    protected static boolean loadIfExists(File libraryFile) {
+        String libraryName = libraryFile.getAbsolutePath();
+        System.out.println("Library name: " + libraryName);


Need to remove this System.out.println and the others or convert them to debugs.

Left from debug. Removed.

johnpeck-us-ibm · 2026-08-03T20:20:24Z

    }

    public static NativeOCKAdapterNonFIPS getInstance() {
+        System.out.println("Using OCK non-FIPS adapter.");


Same as above.

Left from debug. Removed.

johnpeck-us-ibm · 2026-08-04T16:39:47Z

+
+    @Override
+    public void validateLibraryLocation() throws ProviderException, OpenSSLException {
+        /*if (NativeOpenSSLImplementation.requirePreloadOSSL == false) {


Do we not need this to maybe help us determine where the OpenSSL DLL is coming from?

We could add a JNI method to do this, but the question is whether we need this given that it's not like OCK that is provided through a binary. In this case, the user provides their own OpenSSL library.

johnpeck-us-ibm · 2026-08-04T16:57:26Z

+
+    if (!(digestAlgoChars = (const char *)(*env)->GetStringUTFChars(env, digestAlgo, NULL))) {
+        throwOSSLException(env, 0, "DIGEST_create: GetStringUTFChars() failed");
+        goto cleanup;


This should be a return here instead of goto.

johnpeck-us-ibm · 2026-08-04T18:06:19Z

+    }
+
+    // Everything succeeded. Set digestId to created EVP_MD_CTX.
+    digestId = (jlong)((intptr_t)mdCtx);


Should this be (intptr_t) (intptr_t*) instead?

The type intptr_t is supposed to hold pointers itself, so we don't need a intptr_t *.

thu-ibm · 2026-08-05T18:53:17Z

+
+        try {
+            //long osslContextId =  NativeOpenSSLImplementation.initializeOSSL(this.useFIPSMode);
+            long osslContextId = 0;


It appears in this case OpenSSL context is never initialized since the real call is commented out

That is because the OpenSSL context is not yet needed in the use case I'm introducing, given that we decided not to do FIPS at the moment. So, I only left this here for future use and is not needed now.

thu-ibm · 2026-08-05T18:58:11Z

+    }
+
+    public static NativeOpenSSLAdapterNonFIPS getInstance() {
+        System.out.println("Using OpenSSL non-FIPS adapter.");


Using System.out.println pollutes stdout in production

Sorry, those were leftovers from debugging. Removing them.

thu-ibm · 2026-08-05T19:10:13Z

+     * and must match those defined in native/openssl/ExceptionCodes.h.
+     */
+    public static final int GKR_FIPS_MODE_INVALID = 0x00000001;
+    public static final int GKR_OCK_ATTACH_FAILED = 0x00000002;


Error constants like GKR_OCK_ATTACH_FAILED are OCK-specific

Removed the 2 that are irrelevant and kept the two that are used in common parts. Code here can be reworked in a future PR to not use these constants at all.

thu-ibm · 2026-08-05T19:17:24Z

+import java.util.Hashtable;
+import java.util.Map;
+
+public class OpenSSLException extends NativeException {


NativeException appears to be an OCK-specific base class

I'm not sure what you mean here. NativeException is supposed to be a superclass for all exceptions coming from native code. So, native code that uses OCK throws an OCKException, whereas the new digest code that uses OpenSSL throws an OpenSSLException.

In NativeException.java, the naming in the following gives me the impression they are used for OCK.

public static final int GKR_FIPS_MODE_INVALID = -1;

    public static final int GKR_OCK_ATTACH_FAILED = -1;
    public static final int GKR_DECRYPT_FINAL_BAD_PADDING_ERROR = -1;
    public static final int GKR_UNSPECIFIED = -1;

Yeah, I can see why. But I only kept them for the reasons mentioned in #1492 (comment). We'll remove them in the future.

thu-ibm · 2026-08-05T19:19:41Z

+#include "Utils.h"
+#include <string.h>
+
+int debug = 0;  // FIXME


All gslogMessage calls always print to stderr regardless of the flag value

This is following the same pattern that all OCK native code has. Do you think we should change this to have different levels of logging? We could open an issue to do this everywhere if we want.

With this change, all appropriate code is added to support the use of OpenSSL as a backend. That includes: - Main Java class to load the libraries required and offer native methods. - Adapter Java classes to smoothly integrate without changes with existing code. - Makefiles to compile and link required C code to use OpenSSL. - Additional test tags and general test setup to allow the execution of appropriate tests with the new backend. Additionally, the first set of algorithms, namely the message digests, are implemented. The aforementioned tags are, also, added to the corresponding tests. Signed-off-by: Kostas Tsiounis <kostas.tsiounis@ibm.com>

KostasTsiounis force-pushed the openssl_backend branch from ff3a354 to 26a5ca2 Compare May 22, 2026 20:25

KostasTsiounis force-pushed the openssl_backend branch from 04bc9c2 to d4a4c94 Compare June 16, 2026 18:37

KostasTsiounis force-pushed the openssl_backend branch 2 times, most recently from 1b76bd7 to 31add61 Compare July 7, 2026 20:28

KostasTsiounis force-pushed the openssl_backend branch 2 times, most recently from 8920c23 to 0e09aab Compare July 21, 2026 15:39

jasonkatonica requested a review from thu-ibm July 21, 2026 18:14

KostasTsiounis force-pushed the openssl_backend branch from c43bb68 to 117b14c Compare July 31, 2026 00:05

KostasTsiounis marked this pull request as ready for review July 31, 2026 00:05

KostasTsiounis requested review from JinhangZhang, Mohit-Rajbhar100698, jasonkatonica, johnpeck-us-ibm and taoliult July 31, 2026 00:06

johnpeck-us-ibm requested changes Aug 4, 2026

View reviewed changes

thu-ibm reviewed Aug 5, 2026

View reviewed changes

KostasTsiounis requested review from johnpeck-us-ibm and thu-ibm August 6, 2026 17:43

taoliult reviewed Aug 6, 2026

View reviewed changes

Comment thread src/test/java/ibm/jceplus/junit/tests/TestArguments.java

KostasTsiounis force-pushed the openssl_backend branch from dea939a to 1bb6a35 Compare August 6, 2026 20:45

KostasTsiounis requested a review from taoliult August 6, 2026 20:46

KostasTsiounis added 3 commits August 7, 2026 12:16

Fix wrong signature

bc12610

Address review comments

555ccec

KostasTsiounis force-pushed the openssl_backend branch from 1bb6a35 to 555ccec Compare August 7, 2026 16:16

KostasTsiounis changed the title ~~Openssl backend~~ Support OpenSSL backend and implement message digest Aug 7, 2026

Uh oh!

Conversation

KostasTsiounis commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

johnpeck-us-ibm commented Jun 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

KostasTsiounis commented May 22, 2026 •

edited

Loading