gnodet-bot commented on code in PR #27500:
URL: https://github.com/apache/camel/pull/27500#discussion_r4207442125
##########
components/camel-pqc/src/main/docs/pqc-component.adoc:
##########
@@ -91,17 +93,16 @@ BouncyCastle constants (`ml_dsa_87`) is accepted as an
alias of the canonical na
| `MLKEM` | `ML-KEM-512` (default), `ML-KEM-768`, `ML-KEM-1024`
| `SLHDSA` | `SLH-DSA-SHA2-128S`, `SLH-DSA-SHAKE-256F`, ... (see
`SLHDSAParameterSpec`)
| `FALCON` | `FALCON-512`, `FALCON-1024`
-| `DILITHIUM` | `DILITHIUM2`, `DILITHIUM3`, `DILITHIUM5`
-| `SPHINCSPLUS` | `sha2-128s`, ... (see `SPHINCSPlusParameterSpec`)
-| `PICNIC` | `picnicl1fs`, ... (see `PicnicParameterSpec`)
-| `KYBER` | `kyber512`, `kyber768`, `kyber1024`
+| `DILITHIUM` | `ML-DSA-44`, `ML-DSA-65`, `ML-DSA-87` (default)
+| `SPHINCSPLUS` | The `SLHDSA` parameter sets, for example `SLH-DSA-SHA2-128S`
(default)
+| `KYBER` | `ML-KEM-512`, `ML-KEM-768`, `ML-KEM-1024` (default); `kyber512`,
`kyber768` and `kyber1024` are accepted as aliases
| `NTRU` | `ntruhps2048509`, ... (see `NTRUParameterSpec`)
| `NTRULPRime` | `ntrulpr653`, ... (see `NTRULPRimeParameterSpec`)
| `SNTRUPrime` | `sntrup761`, ... (see `SNTRUPrimeParameterSpec`)
| `BIKE` | `bike128`, `bike192`, `bike256`
| `HQC` | `hqc128`, `hqc192`, `hqc256`
-| `CMCE` | `mceliece348864`, ... (see `CMCEParameterSpec`)
-| `FRODO` | `frodokem640aes`, ... (see `FrodoParameterSpec`)
+| `CMCE` | `mceliece460896`, `mceliece8192128f` (default), ... (see
`org.bouncycastle.jcajce.spec.CMCEParameterSpec`)
Review Comment:
⚠️ **CMCE default inconsistency between tables**
This table marks `mceliece8192128f` as `(default)` for CMCE. However,
`pqc-key-lifecycle.adoc` (line 1218) lists the lifecycle manager default as
`mceliece460896`, which matches the actual code in
`KeyAlgorithmSupport.getDefaultParameterSpec()` (changed from `mceliece348864`
→ `mceliece460896` in this PR).
The two tables describe different defaults (component vs lifecycle manager),
but labelling them differently without explanation is confusing. Consider
clarifying the distinction, e.g.: `mceliece8192128f` (component default),
`mceliece460896` (lifecycle manager default).
##########
components/camel-pqc/src/main/docs/pqc-component.adoc:
##########
@@ -380,17 +381,10 @@ All other signature algorithms follow the exact same
route pattern shown above f
|SPHINCS+
|`SPHINCSPLUS`
-|SPHINCS+
-|BCPQC
-|sha2_128s
-|`PQCDefaultSPHINCSPlusMaterial`
-
-|Picnic
-|`PICNIC`
-|Picnic
-|BCPQC
-|picnicl1fs
-|`PQCDefaultPicknicMaterial`
+|SLH-DSA
+|BC
+|SLH-DSA-SHA2-128s
Review Comment:
🔤 **Casing inconsistency: `SLH-DSA-SHA2-128s` vs `SLH-DSA-SHA2-128S`**
This algorithm table entry uses lowercase `s` (`SLH-DSA-SHA2-128s`), but the
parameter-sets table (line 43) and the SPHINCSPLUS entry (line 50 in this PR)
both use uppercase `S` (`SLH-DSA-SHA2-128S`). The canonical BouncyCastle
constant name uses uppercase `S` — please align this entry.
##########
components/camel-pqc/src/main/java/org/apache/camel/component/pqc/lifecycle/KeyAlgorithmSupport.java:
##########
@@ -149,13 +151,13 @@ public static AlgorithmParameterSpec
getDefaultParameterSpec(String algorithm) {
case "SABER":
return SABERParameterSpec.lightsaberkem128r3;
case "FRODO":
- return FrodoParameterSpec.frodokem640aes;
+ return FrodoKEMParameterSpec.frodokem976aes;
case "BIKE":
return BIKEParameterSpec.bike128;
case "HQC":
return HQCParameterSpec.hqc128;
case "CMCE":
- return CMCEParameterSpec.mceliece348864;
+ return CMCEParameterSpec.mceliece460896;
Review Comment:
⚠️ **Breaking default changes for FRODO and CMCE — migration warning
missing**
This PR changes the lifecycle manager defaults:
- `FRODO`: `frodokem640aes` → `frodokem976aes`
- `CMCE`: `mceliece348864` → `mceliece460896`
These changes are forced by BC 1.86 dropping the old parameter sets
(confirmed by `testParameterSetsDroppedByBouncyCastleRejected`), but the
consequence is a **breaking change for any user with existing keys**: keys
generated with the old defaults are incompatible with keys generated with the
new defaults — they cannot interoperate.
The PR should include a migration note in the docs (or a
`CHANGELOG`/`BREAKING-CHANGES` section) advising users who rely on default key
generation to regenerate keys when upgrading from BC 1.85 to 1.86.
--
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]
