Delivering liboqs-java as a JCE provider

[pruthig]

Hi Team,
Can we refactor the code and make changes so that liboqs-java can be used as JCE provider? It means, for instance, creating a subclass of SignatureSpi and invoke wrapper functions from the member functions of that subclass. It will help a lot of people who want to pick it as a plug-and-play artifact based on JCE provider framework.

[baentsch]

Sounds like a sensible enhancement @pruthig . Would you be willing to keep maintaining this going forward? You may have seen that this language wrapper is one of our least well "looked after" sub projects.....

[johngray-dev]

I can verify that this approach works because I wrote a JCE based wrapper for one of our internal company projects. It allows me to plugin the algorithms from LibOQS and use them pretty simply throughout a legacy code base.

[baentsch]

Thanks for letting us know, @johngray-dev . Any interest to contribute that (back?) to the community? Might entice more people to look after the Java wrapper. And if I may ask one more question: Why did you do it this way and not use BouncyCastle instead?

[johngray-dev]

I might be enticed... but to do it properly may require an ASN.1 library and I'm not sure standard Java itself lets arbitrary ASN.1 be generated (I don't think they expose it anyway).

There are a couple of reasons we did it ourself:

• We have an Entrust Java toolkit that has been around for about 25 years and it is used in lots and lots of places. It is a commercial toolkit and also used internally by lots of our products. So for prototyping upgrades to these newer algorithms it makes it much easier to simply drop in an update and use standard JCE calls to access the new algorithms.
• It turns out a JNI wrapper around native PQ implementations is MUCH faster than native Java implementations. David Hook (of Bouncy Castle fame), presented analysis they had done in this vein at ICMC 2024. It turned out a libOQSWrapped Java implementation is about 9X faster on ML-KEM and some multiple on Signatures (2 or 3x or more), but I don't remember the exact figure. At some point this may change once CPU start adding new math instructions that optimize the types of algorithms needed for the new PQ algorithm, but at the moment there is quite a difference.

[jimouris]

Thanks for the feedback @johngray-dev.

libOQSWrapped Java implementation is about 9X faster on ML-KEM and some multiple on Signatures (2 or 3x or more), but I don't remember the exact figure.

Great to hear that!