What is the correct Quarkus dependency to add to use BouncyCastle?

[jvanzyl]

Specifically there are classes in bcprov-jdk15on:1.70 that I want to use and adding quarkus-security didn't seem to work. There were two classes specifically that I had to @RegisterForReflection:

• KeyPairGeneratorSpi.EdDSA.class
• KeyPairGeneratorSpi.XDH.class

Is there another dependency I should be using or is this expected and using custom registration is the way to go?

Thanks,

Jason

[sberyozkin]

@jvanzyl Hi, yes, as discussed on Zulip, adding specific BouncyCastle dependencies is required for now, https://quarkus.io/guides/security-customization#bouncy-castle, so you'd add a BC security provider in the configuration and that should be it. The EdDSA generator should certainly work in native mode, but not sure about XDH - does it work for you if you follow the documentation, without having to add @RegisterForReflection ?

[jvanzyl]

I need to use @RegisterForReflection and then everything is fine.

[sberyozkin]

@jvanzyl I've created this branch:
https://github.com/sberyozkin/quarkus/pull/new/bc_keypair_ecdsa_xdh.

Referring to XDH directly does not work for me but the BC code treats X448 and X25519 as the XDH family. Which of these 2 values, X448 and X25519 do you use ?

[jvanzyl]

This is the configuration I use that allows me to get the app to build with graalvm:

import io.quarkus.runtime.annotations.RegisterForReflection;
import org.bouncycastle.jcajce.provider.asymmetric.edec.KeyPairGeneratorSpi;
import org.pgpainless.implementation.BcImplementationFactory;
import org.pgpainless.sop.SOPImpl;

@RegisterForReflection(targets = {
    SOPImpl.class,
    BcImplementationFactory.class,
    KeyPairGeneratorSpi.EdDSA.class,
    KeyPairGeneratorSpi.XDH.class,
})
public class ProvisioReflectionConfiguration {}

[sberyozkin]

@jvanzyl Hmm..., KeyPairGenerator.getInstance("XDH", "BC"); fails for me even in JVM mode... Is it bcprov-jdk15on-1.69 that you use ?

[jvanzyl]

I'm using 1.70

[sberyozkin]

@jvanzyl Not sure what is going on, I see KeyPairGenerator.getInstance("XDH", "BC"); failing with:

Caused by: java.lang.IllegalStateException: generator not correctly initialized
	at org.bouncycastle.jcajce.provider.asymmetric.edec.KeyPairGeneratorSpi.generateKeyPair(KeyPairGeneratorSpi.java:93)
	at java.base/java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:722)
	at io.quarkus.it.bouncycastle.BouncyCastleEndpoint.generateXdhKeyPair(BouncyCastleEndpoint.java:60)

where the relevant code is:

public static final class XDH
        extends KeyPairGeneratorSpi
    {
        public XDH()
        {
            super(XDH);
        }
    }
   KeyPairGeneratorSpi(int algorithmDeclared)
    {
        this.algorithmDeclared = algorithmDeclared;

        if (getAlgorithmFamily(algorithmDeclared) != algorithmDeclared)
        {
            this.algorithmInitialized = algorithmDeclared;
        }
    }
    private static int getAlgorithmFamily(int algorithm)
    {
        switch (algorithm)
        {
        case Ed25519:
        case Ed448:
            return EdDSA;
        case X25519:
        case X448:
            return XDH;
        default:
            return algorithm;
        }
    }

So as you, in case of XDH it is XDH which is returned from getAlgorithmFamily and hence the condition in the constructor, if (getAlgorithmFamily(algorithmDeclared) != algorithmDeclared) is not triggered, algorithmInitialized remains 0 and this is why the exception is reported:

public KeyPair generateKeyPair()
    {
        if (algorithmInitialized == 0)
        {
            throw new IllegalStateException("generator not correctly initialized");
        }

But it is not a big problem. I think it makes sense to support various algorithms at the Quarkus level, those one which are actually used as BC supports dozens of them, and for the users avoid having to know the internal BC class names. I suppose I'll just add EdDSA for now...

thanks