Details regarding the bcpqc-fips artifact and BouncyCastlePQCProvider

[rymarm]

Hi! I found a Bouncy Castle artifact, bcpqc-fips, in the Maven repository with the following description:

The Bouncy Castle Non-Certified PQC APIs contains non-certified implementations of ML-KEM, ML-DSA, and SLH-DSA sutiable for use with the BCFIPS provider.

However, this is almost the only place the artifact is mentioned - it isn't listed in either the documentation or the release notes. I'm curious: how is it intended to be used? Also, is there a plan to maintain this artifact until BC-FIPS 2.2.0 is released, or even after that?

Are there code samples available for this? I assumed we need to register BouncyCastlePQCProvider alongside BouncyCastleFipsProvider in the Security context to bring in PQC support. Is that correct?

I've managed to run a few code samples, but I'd appreciate any insights or details you could share regarding the bcpqc-fips module!

[ECD5A]

A concrete detail from the published 2.1.0 artifact may help clarify the intended boundary:

• the bcpqc-fips POM depends on bc-fips in the [2.1.0, 2.2.0) range; and
• the JAR contains org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider.

That makes it look like an add-on to BCFIPS rather than a replacement for BouncyCastleFipsProvider. The important compliance distinction is that the PQC implementations are explicitly described as non-certified. Registering BouncyCastlePQCProvider alongside BCFIPS may make ML-KEM, ML-DSA, and SLH-DSA available, but it should not be interpreted as extending certificate #4943 or making those operations FIPS-approved.

For a mixed deployment, I would select the provider explicitly for each algorithm instead of relying on provider order, and document whether the application is running in approved-only or non-approved mode.

Could a maintainer confirm whether this provider pairing is the supported integration path and point to the current example or release-note entry for bcpqc-fips?

[xnox]

For purePQC - it sort of is awkward to use; may as well just use regular bouncycastle releases.
For hybridPQC - this is not compliant as NIST guidance wants all portions of the algorithms to come from fips modules (can be multiple, but need validated). There are many non-java modules which do split themselves into multiple validated modules.

[rymarm]

The bcpqc-fips module — or a hybrid PQC approach, as you mentioned — is useful when you want to add PQC algorithm support while allowing users to run an application in either FIPS-compliant or non-compliant mode.

For example, Java 17 doesn't support PQC algorithms out of the box, so third-party solutions are required. However, since running the standard Bouncy Castle provider simultaneously with Bouncy Castle FIPS isn't possible, the bcpqc-fips module comes in very handy. It lets you use PQC algorithms for general purposes while continuing to use the Bouncy Castle FIPS module for compliant mode.