oscerd opened a new pull request, #28106: URL: https://github.com/apache/camel/pull/28106
Fixes [CAMEL-25802](https://issues.apache.org/jira/browse/CAMEL-25802) — the three items with real behaviour behind them. The remaining cosmetic items on that issue are deferred; see the bottom. ## 1. Five key materials used the provider default RNG Sixteen of the twenty-one `PQCDefault*Material` classes pass `SecureRandomHelper.getSecureRandom()`. Five did not: ```java kpGen.initialize(FalconParameterSpec.falcon_1024); // Falcon kpGen.initialize(MayoParameterSpec.mayo5); // MAYO kpGen.initialize(SnovaParameterSpec.SNOVA_24_5_5_SHAKE_SSK); // SNOVA kpGen.initialize(new LMSKeyGenParameterSpec(...)); // LMS kpGen.initialize(new LMSHSSKeyGenParameterSpec(...)); // HSS ``` `SecureRandomHelper` exists precisely to centralise that choice, and `PQCComponent.resolveKeyPair` always seeds — so the same algorithm got a different RNG depending on whether `parameterSpec` was set. All twenty-one now seed from the shared helper. No key format or parameter set changes. ## 2. `parameterSpec` was refused for MAYO and SNOVA on a false premise ```java * algorithms (XMSS, XMSSMT, LMS, HSS) and MAYO/SNOVA have no name-addressable BouncyCastle parameter spec and are * therefore not supported here ``` Verified against `bcprov-jdk18on-1.86.jar`: ``` public static org.bouncycastle.pqc.jcajce.spec.MayoParameterSpec fromName(java.lang.String); public static org.bouncycastle.pqc.jcajce.spec.SnovaParameterSpec fromName(java.lang.String); ``` Both exist, and neither algorithm is stateful, so the exclusion had no basis — MAYO and SNOVA users were locked to one hardcoded security level with no way to pick another short of registering their own `KeyPair` bean. Both are now resolvable. The stateful hash-based algorithms remain excluded, correctly: `XMSSParameterSpec` genuinely has no `fromName`. `PQCParameterSpecResolverTest` asserted `assertFalse(isSupported("MAYO"))`, encoding the wrong premise; updated. ## 3. Two aliases were told to switch to themselves `DILITHIUM` and `SPHINCSPLUS` were in `NON_FIPS_PQ_SIGNATURES`, which drives: > PQC signature algorithm {} is not part of NIST FIPS 204/205. Consider using ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) > for production hybrid deployments. But `DILITHIUM("ML-DSA", "BC")` and `SPHINCSPLUS("SLH-DSA", "BC")` resolve to precisely those algorithms — the module already says so in `PQCParameterSpecResolver`. Both are removed from the set. `FALCON`, `MAYO`, `SNOVA`, `XMSS` and `XMSSMT` still warn. ## Tests New `PQCMaterialConsistencyTest` guards the rules rather than the instances, so the next clone-and-tweak cannot reintroduce the drift: it walks the material sources asserting every one seeds from `SecureRandomHelper`, checks MAYO/SNOVA resolve every documented level while the stateful algorithms still do not, and asserts the two aliases stay out of the non-FIPS set. Full `camel-pqc` build green: 245 tests, 0 failures. ## Deferred from the umbrella issue Left out deliberately, as cosmetic or needing a separate decision: - **Residual `"BCPQC"` provider strings** on 12 enum constants. I verified in BC 1.86 that `FALCON`, `XMSS` and `XMSSMT` are registered identically under both `BC` and `BCPQC`, so this is naming inconsistency with no behavioural effect. - **The `label` `@UriPath`** — declared `required = true` with no getter, no setter, and `createEndpoint` never reading `remaining`. Making it bindable or dropping it both change the published catalog, so it wants its own call. - **Metrics coverage and the missing class Javadoc** on the 21 material classes — additive work rather than a fix. The structural fix the issue really points at is replacing the clone-and-tweak material classes with one parameterised factory driven by `PQCParameterSpecResolver`; that would remove this whole defect class, along with the missing-switch-arm family behind #28098. Worth a separate discussion. --- _Reported, analysed and fixed by Claude Code (AI agent) on behalf of @oscerd._ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
