Problems with BouncyCastle in native images

[erik-wramner]

I have a Quarkus application that works with encryption, signatures and digests using BouncyCastle. It works well in Java mode, but in native mode I get:
org.bouncycastle.operator.OperatorCreationException: cannot create signer: no such algorithm: SHA256WITHRSA for provider BC at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source) at org.bouncycastle.cms.jcajce.JcaSimpleSignerInfoGeneratorBuilder$NamedHelper.createContentSigner(Unknown Source)

and:

java.security.NoSuchAlgorithmException: no such algorithm: SHA256WITHRSA for provider BC at sun.security.jca.GetInstance.getService(GetInstance.java:87)

There are probably other similar problems that I have yet to find. My guess is that I need to register classes for reflection, but the whole point of indirection such as MessageDigest.getInstance is that the actual classes are unknown. Finding and registering the necessary classes for SHA256WITHRSA is certainly doable, but going through all the possible digests and signatures and encryption algorithms to search for this is painful to say the least.

I'm considering writing a tool that dumps all classes in the BC jars to register every single one just in case.

Could there be something I have missed, or am I on the right track here? Is there a better way?

I'm using the BC versions pulled in by the Quarkus BOM with 2.12.3, SSL is enabled in the configuration. I tried to set quarkus.security.security-providers=BC, but got a warning that it was an unknown option? BouncyCastle is registered at startup without issues:
Security.addProvider(new BouncyCastleProvider());

I'm grateful for any hints, as this is a blocker. Running the application in Java mode is an option, but that would be a waste.

[gsmet]

/cc @sberyozkin

[sberyozkin]

@erik-wramner Can you please try only do quarkus.security.security-providers=BC, without creating it manually, and make sure io.quarkus:quarkus-security is on the classpath ?

Right now it also registers many of the individual algorithms for reflection, however may be we should indeed consider just registering all of them, the only problem there is that there is a massive number of them, where an application uses a few at most, with many of those algorithms being quite specific, so my thinking has been so far that we should cover most of the well-known ones and let users register others as needed.

[erik-wramner]

Thanks @sberyozkin, adding io.quarkus:quarkus-security helped. Now SHA256WITHRSA is working.

However, I'm still a bit worried here. Our application is not in control of the algorithms it must support. We get messages from other products and based on the payload we need to support different digests, signature algorithms and encryption algorithms. Mostly we're talking SHA-x and 3DES and AES with varying strengths, key types and options. I would feel much safer if it was possible to set an option to register everything so that we can know that an unexpected message doesn't blow up.

[sberyozkin]

@erik-wramner Np, and makes sense, can you please open an enhancement request ? I recall seeing the code in Camel Quarkus registering all the algorithms, I guess we can optionally do the same

[erik-wramner]

Registered #28250