Add Ability to use Config File by johnpeck-us-ibm · Pull Request #1167 · IBM/OpenJCEPlus

johnpeck-us-ibm · 2026-02-10T17:02:35Z

Added the ability to use a config file to create a a new OpenJCEPlus provider based on that file

Signed-off-by: John Peck 140550562+johnpeck-us-ibm@users.noreply.github.com

jasonkatonica · 2026-02-11T14:43:48Z

src/test/ProviderDefAttrs.config

+ * under the terms provided by IBM in the LICENSE file that accompanied
+ * this code, including the "Classpath" Exception described therein.
+ */
+


In general I was envisioning a file format that users could more easily modify and understand, instead of parsing java code in order to setup the provider. I think we would want to choose from xml, json, or Java properties files and use a parsing library. Java properties files seem like the most common in this area such as the java.security file.

Having the file versioned would allow us to grow into every more complex file formats and options.

We can do that instead. This is more like what you would have to do if you were creating a provider. So, this makes it easy to take an existing provider and add attributes etc to a new provider, which is kind of how I would see this used. Otherwise, it will be a lot of work for some one to translate what is already in a provider to create a file. Now I guess if we document this well an AI tool could be used to do the translation. This also makes is pretty obvious what the service will contain. Where property pairs may not.

Note: I am not set on the current format, and can be convinced otherwise.

johnpeck-us-ibm · 2026-03-02T20:50:02Z

I got the properties working. Now just need to deal with defaults

johnpeck-us-ibm · 2026-03-18T19:20:57Z

I have added two new files. to base. BackendCryptoInterface and BankendCryptoSelector. These are files we will need for the selection of the backend. The Basically when a function in base needs to determine the back end to use it can call the BankendCryptoselector with the provider, the type (cipher, message digest, etc) and the algorithm it will return the backend. All the bankend calls will be of the format in BackendCryptoInterface. We may need to remove some calls and modify the function parameters but this is a start. So for example in Digest.java in where it calls NativeInterface.DIGEST_create today in would first call (BankendCryptoSelector.selectBackend(Provider, "Digest", )).DIGEST_create

johnpeck-us-ibm · 2026-04-08T15:40:38Z

Moved test cases and added documentation.

Added the ability to use a config file to create a a new OpenJCEPlus provider based on that file. Update the providers to use this config to create FIPS and non-FIPS Signed-off-by: johnpeck-us-ibm <johnpeck@us.ibm.com>

jasonkatonica · 2026-04-13T13:57:38Z

src/main/java/com/ibm/crypto/plus/provider/DefaultProviderAttrs.java

+                + "KeyGenerator.kda-hkdf-with-sha256.alias.add = kda-hkdf-with-sha-256\n"
+                + "Service.KeyGenerator.kda-hkdf-with-sha256 = com.ibm.crypto.plus.provider.HKDFGenerator$HKDFwithSHA256\n"
+
+                + "KeyGenerator.kda-hkdf-with-sha384.alias.add = kkda-hkdf-with-sha-384\n"


This should be kkda-hkdf-with-sha-384 instead of kda-hkdf-with-sha-384 like the others.

jasonkatonica · 2026-04-13T14:00:36Z

src/main/java/com/ibm/crypto/plus/provider/OpenJCEPlus.java

+        try {
+            ProviderServiceReader config = new ProviderServiceReader(new BufferedReader(new StringReader(DefaultProviderAttrs.getConfigString())));  
+            List<ProviderServiceReader.ServiceDefinition> services = config.readServices();
+            for (ProviderServiceReader.ServiceDefinition service : services) {
+                putService(new OpenJCEPlusService(jce, service.getType(), service.getAlgorithm(),
+                    service.getClassName(), service.getAliases().toArray(new String[service.getAliases().size()]), service.getAttributes()));
+            }
+        } catch (IOException e) {
+            throw new InvalidParameterException("Error configuring OpenJCEPlus provider - " + e.getMessage()); 
+        }    
+


This code ( lines 99 - 108 ) is very similar if not exactly the same as the OpenJCEPlusFIPS class. Seems we could put this into a private helper method in the OpenJCEPlusProvider class that can be used in both providers.

jasonkatonica · 2026-04-13T14:02:11Z

src/main/java/com/ibm/crypto/plus/provider/OpenJCEPlus.java

+                    service.getClassName(), service.getAliases().toArray(new String[service.getAliases().size()]), service.getAttributes()));
+            }
+        } catch (IOException e) {
+            throw new InvalidParameterException("Error configuring OpenJCEPlus provider - " + e.getMessage()); 


When throwing the exception on this line can we throw the entire e in the caused by for the exception instead of just the message.

jasonkatonica · 2026-04-13T14:05:14Z

src/main/java/com/ibm/crypto/plus/provider/OpenJCEPlusFIPS.java

@@ -140,583 +153,6 @@ public OpenJCEPlusFIPS() {
        }
    }



OpenJCEPlus has both a configure(String) and configure(BufferedReader) method. I dont see these added here to the FIPS provider. For consistancy and for allowing support / extension / changes of the OpenJCEPlus-xxx providers in the future should these be added here also?

jasonkatonica · 2026-04-13T14:07:14Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+ * This class reads files containing putService() calls in the format:
+ * putService(new OpenJCEPlusService(provider, "Type", "Algorithm", "ClassName", aliases));
+ * 
+ * Example usage:
+ * <pre>
+ * ProviderServiceReader reader = new ProviderServiceReader("services.txt");
+ * List<ServiceDefinition> services = reader.readServices();
+ * for (ServiceDefinition service : services) {
+ *     System.out.println(service.getType() + ": " + service.getAlgorithm());
+ * }


We are using properties now from the file so this javadoc should reflect that change.

jasonkatonica · 2026-04-13T14:09:44Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+     * @param filePath the path to the file containing service definitions
+     */
+    public ProviderServiceReader(String filePath) {
+        this.filePath = filePath;


Can we check for null here?

jasonkatonica · 2026-04-13T14:10:42Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+                throw new IOException("File not found: " + filePath);
+            } else {
+                // this filePath != null && Files.exists(Paths.get(filePath))
+                rd = new BufferedReader(new FileReader(filePath));


We should ensure that rd is always closed.

jasonkatonica · 2026-04-13T14:12:15Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+                }
+            }
+        } catch (Exception e) {
+            throw new IOException("File issue: " + e.getMessage());


Please throw e in the caused by of the exception so its not hidden if an error occurs.

jasonkatonica · 2026-04-13T14:13:30Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+            if (value != null) {
+                String[] aliases = value.split("\\s*,\\s*");
+                for (String alias : aliases) {
+                    Aliases.add(alias);


Should we ensure that the alias is not null or empty string due to the regex above?

jasonkatonica · 2026-04-13T14:14:35Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+     * @return a list of alias strings
+     */
+    private List<String> processAliases(String[] parts, Properties defaultPr, Properties configPr, Set<String> configAliases) {
+        List<String> Aliases = new ArrayList<>();


Perhaps this should be lower case since its a local variable.

jasonkatonica · 2026-04-13T14:31:44Z

src/main/java/com/ibm/crypto/plus/provider/OpenJCEPlus.java

-            putService(new OpenJCEPlusService(jce, "KeyGenerator", "kda-hkdf-with-sha224",
-                    "com.ibm.crypto.plus.provider.HKDFGenerator$HKDFwithSHA224", aliases));
+    public OpenJCEPlus(ProviderServiceReader config) {
+        super("OpenJCEPlus-" + config.getName(), config.getDesc());


Should we check that the name and description is not null or empty?

Also we should add the name of the provider we use in the debug on line 138.

jasonkatonica · 2026-04-13T14:34:09Z

src/main/java/com/ibm/crypto/plus/provider/ProviderServiceReader.java

+                    throw new IOException("Invalid key: " + key);
+                }
+            }
+


At this point in the code should we validate a few of the parameters to ensure we read them from the config file. This should include description and default and name at least from above that have been expected to be parsed.

jasonkatonica · 2026-04-13T14:44:29Z

PROVIDER_CONFIG_FORMAT.md

+  2. Config file `.add` operations are applied
+  3. Config file `.delete` operations are applied
+  4. Config file `.replace` operations are applied (clears list first)
+- Only one operation (add/delete/replace) per service type and algorithm is expected


What happens if we dont follow this rule?

jasonkatonica · 2026-04-13T14:46:29Z

PROVIDER_CONFIG_FORMAT.md

+## ServiceDefinition Class
+
+The parser creates `ServiceDefinition` objects with:
+
+```java
+public class ServiceDefinition {
+    private final String type;              // Service type (e.g., "Cipher")
+    private final String algorithm;         // Algorithm name (e.g., "AES")
+    private final String className;         // Implementation class
+    private final List<String> aliases;     // List of alias names
+    private final Map<String, String> attributes;  // Attribute key-value pairs
+}
+```


I would be ok leaving code out of the user facing documenation for this feature unless there is a reason?

jasonkatonica · 2026-04-13T14:48:41Z

PROVIDER_CONFIG_FORMAT.md

@@ -0,0 +1,451 @@
+# Provider Configuration File Format Documentation
+
+This document describes the format and syntax for provider configuration files used in OpenJCEPlus, based on the `ProviderServiceReader.java` implementation and example configuration files `ProviderDefAttrs.config` and `ProviderFIPSDefAttrs.config`.


Giving the user a direct link in the code to these two files would be helpful for them to have as "examples". Over time we could also provide and link other test configuration files such as OpenSSL related files.

jasonkatonica · 2026-04-13T14:51:09Z

PROVIDER_CONFIG_FORMAT.md

+
+#### Key Structure:
+- **Part 0**: Must be `Service` (case-insensitive)
+- **Part 1**: Service type (e.g., Cipher, Signature, MessageDigest)


Should we give the reader all possible values here in case they are not familiar with the JCE service type definitions?

There is a section below "Common Service Types:" that seems to cover them. Maybe we link to that spot here?

jasonkatonica · 2026-04-13T14:57:39Z

src/main/java/com/ibm/crypto/plus/provider/OpenJCEPlus.java

@@ -111,1123 +123,45 @@ public OpenJCEPlus() {
        }


I think it would be great for us to print in debugs the final services that are being registered after all the parsing, replacing, and joining operations have occurred so its clear what we registered along with various other service attributes, aliases, provider name, and classes we ended up with after we are done processing. Perhaps we could add a helper function to the OpenJCEPlusProvider to print everything registered in both the OpenJCEPlus and OpenJCEPlusFIPS class.

johnpeck-us-ibm self-assigned this Feb 10, 2026

johnpeck-us-ibm marked this pull request as draft February 10, 2026 17:03

jasonkatonica reviewed Feb 11, 2026

View reviewed changes

johnpeck-us-ibm requested a review from jasonkatonica March 2, 2026 20:49

johnpeck-us-ibm force-pushed the ProvUptOpenSSLV3 branch from 1026251 to 912fd2b Compare March 12, 2026 17:40

johnpeck-us-ibm requested review from KostasTsiounis March 18, 2026 19:06

johnpeck-us-ibm force-pushed the ProvUptOpenSSLV3 branch 2 times, most recently from fb660bd to 16d4c4b Compare April 7, 2026 15:27

johnpeck-us-ibm marked this pull request as ready for review April 7, 2026 17:01

johnpeck-us-ibm requested review from JinhangZhang and taoliult April 7, 2026 17:01

johnpeck-us-ibm force-pushed the ProvUptOpenSSLV3 branch from 6e5c8a4 to 43b5935 Compare April 8, 2026 15:39

Add Ability to use Config File to create Providers

7a56cdb

Added the ability to use a config file to create a a new OpenJCEPlus provider based on that file. Update the providers to use this config to create FIPS and non-FIPS Signed-off-by: johnpeck-us-ibm <johnpeck@us.ibm.com>

johnpeck-us-ibm force-pushed the ProvUptOpenSSLV3 branch from da703e3 to 7a56cdb Compare April 10, 2026 18:39

jasonkatonica requested changes Apr 13, 2026

View reviewed changes

		@@ -0,0 +1,451 @@
		# Provider Configuration File Format Documentation

		This document describes the format and syntax for provider configuration files used in OpenJCEPlus, based on the `ProviderServiceReader.java` implementation and example configuration files `ProviderDefAttrs.config` and `ProviderFIPSDefAttrs.config`.

Conversation

johnpeck-us-ibm commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnpeck-us-ibm commented Mar 2, 2026

Uh oh!

johnpeck-us-ibm commented Mar 18, 2026

Uh oh!

johnpeck-us-ibm commented Apr 8, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

johnpeck-us-ibm commented Feb 10, 2026 •

edited

Loading