Bouncy castle 1.80 - Unable to create content signer with ML-DSA

[bhushan5640]

Both options below fail with the error - cannot create signer: no such algorithm: ML-DSA-65 for provider BCPQC on Bouncy castle v1.80

        ContentSigner contentSigner = new JcaContentSignerBuilder("Dilithium3")
            .setProvider("BCPQC")
            .build(keyPair.getPrivate());
OR
        ContentSigner contentSigner = new JcaContentSignerBuilder("ML-DSA-65")
            .setProvider("BCPQC")
            .build(keyPair.getPrivate());

[ligefeiBouncycastle]

One workaround is to use the standard "BC" provider, which often has broader support for these algorithms. For example: ContentSigner contentSigner = new JcaContentSignerBuilder("ML-DSA-65") .setProvider("BC") .build(keyPair.getPrivate()); Let me know if this helps or if you need further assistance!

[bhushan5640]

Thanks, yes I found that out in the meantime :) But I was expecting it to also work with "BCPQC" provider.

[migueltorresvalls]

What algorithm are you using for keyPair generation?

[yuchunjiao0208]

Both options below fail with the error - cannot create signer: no such algorithm: ML-DSA-65 for provider BCPQC on Bouncy castle v1.80

        ContentSigner contentSigner = new JcaContentSignerBuilder("Dilithium3")
            .setProvider("BCPQC")
            .build(keyPair.getPrivate());
OR
        ContentSigner contentSigner = new JcaContentSignerBuilder("ML-DSA-65")
            .setProvider("BCPQC")
            .build(keyPair.getPrivate());

I am facing the same problem now, it’s frustrating, did you solve the problem yet?

[yuchunjiao0208]

What algorithm are you using for keyPair generation?

I used :KeypairGenerator.getInstance(“Dilithium”,”BCPQC”);

[peterdettman]

@yuchunjiao0208 Did you see https://github.com/bcgit/bc-java/issues/1991#issuecomment-2651966555 ? Note the use of the "BC" provider.

[yuchunjiao0208]

@yuchunjiao0208 Did you see #1991 (comment) ? Note the use of the "BC" provider.

Thank you for reply. But my target now is to generate a Certification with Dilithium (not ML-DSA-65), as the code above.

[migueltorresvalls]

Hi @yuchunjiao0208

ML-DSA is the standarized name for Dilithium. It has 3 security levels, each corresponding to a different dilithium version. For instance, ML-DSA-65 is the standarized name for Dilithium3.

[ligefeiBouncycastle]

Thanks for the discussion. To clarify what's going on, please have a look at the source code:

BouncyCastlePQCProvider.java (lines 41–44)

BouncyCastleProvider.java (around line 134)

From what I understand based on the source and my experience:

Provider Architecture

BCPQC is intended for experimental or development-stage algorithms — mostly those in NIST PQC Round 3/4 and NIST PQC Signature Round 2 — and uses original algorithm names like "Dilithium" or "Falcon".

BC (the standard provider) includes only standardized algorithms and uses NIST-assigned names, such as "ML-DSA-65" (which is the standardized name for Dilithium3).

Why the error occurs

When using BCPQC, algorithm names like "ML-DSA-65" are not recognized because that naming convention only exists in the BC provider.

Similarly, when using BC, algorithm names like "Dilithium" are not registered — only "ML-DSA-65", "ML-DSA-44", etc., are.

Recommendation

So:

If you're using "Dilithium" in key generation or signing, stick with BCPQC.

If you're using "ML-DSA-65" or any other NIST-style name, use the BC provider.

This separation is intentional and reflects how Bouncy Castle maintains a clean boundary between standardized and experimental implementations.

Hope this clears things up!