Potential issues of using the FIPS and non-FIPS versions of the BouncyCastle library in the same project

I'm working on a project where the BouncyCastle Crypto package (non-FIPS) is a dependency of some other 3rd party library. My task is to integrate the BouncyCastle FIPS library to use in our own code. However, the documentation (BC FIPS in 100 mini-book) at https://www.bouncycastle.org/fips-java/BCFipsIn100.pdf, page 11 says:

The provider jar itself has no external dependencies, but it cannot be used in the same JVM as the regular Bouncy Castle provider. The classes in the two jar files do not get along.

I searched for more info on this but didn't really find anything useful.

I've also checked https://github.com/bcgit/bc-java/issues/714, and SpongyCastle is not suitable for our use-case.

My project seems to be working so far with both the FIPS (bc-fips-1.0.2.3.jar) and non-FIPS (bcprov-jdk15on-1.64.jar) jars being present.

So my question is, what exactly should I expect to go wrong if both the FIPS and non-FIPS jars are present in the project?

Note that my project doesn't need to be FIPS compliant per se, just has to provide the user an option to use FIPS compliant cryptography.

Solution

Highly late in the answer, but...

It is true that bc-fips and bcprov don't get along. The reason for that is that they both have the same classes in the same namespace. As such, when parts of the module try to access these classes they'll have security exceptions, because they will use the class from the /other/ module (since it being earlier on the classpath), which will trigger security warnings (the jars are 'closed' to prevent this as it could allow untrusted code to be run if you override such classes by putting them earlier on the classpath). You could argue that the classes should be in different namespace, but sadly they aren't.

Now, you are fine if your bcprov is compatible with bcfips; in that case you can 'switch' bcprov for bcfips (note that your keystores may have a different format, so your keystores may need to be regenerated).

However, this leaves the problem that bcprov may not be compatible with bcfips. bcfips is certified in 2019. bcprov-jdk18on is from 2022. Not only does it use java 8 (not a big issue, usually), but also the interface of these shared classes has changed. That means that code which uses bcprov will call methods in a bouncycastle class which are not available in bcfips. As such, you cannot really swap bcprov and bcfips anymore. Additionaly, bcprov has lot more classes which may be used by your dependency, which are not available in bcfips.

With that in mind, what can you do if you really want fips, but also have a dependency on bcprov? If you want to turn to the dark arts, there is a bit of a loooong way around it:

ensure that bc-fips is first on the classpath, and bc-prov second
have your own classes in the same namespace so you can 'override' those that would route into bc-fips can call the appropriate bc-prov class (or implement those methods where necessary)
and sadly, since the second step will trigger security warnings, you'll have to 'unsecure' the libraries, so maven-unpack-repackage but without the manifest securing it all
and run all that in a JVM which allows such abuse (oracle's jdk for example, expects security providers to be signed. If you unpack-repackage, you can no longer sign the new jar. OpenJDK's doesn't care)

That may be sufficient for your usecase, if you're lucky. Ensure plenty of integration tests to ensure the functionality isn't affected.