oscerd opened a new pull request, #24654:
URL: https://github.com/apache/camel/pull/24654
# CAMEL-23846: Camel-PQC — make the NIST parameter set configurable on the
endpoint
## Motivation
The default key material classes hardcode a single parameter set per
algorithm — `PQCDefaultMLDSAMaterial`
uses **ML-DSA-65**, ML-KEM defaults to **ML-KEM-512**, Falcon to 512 — and
the lifecycle
`generateKeyPair` path only called the 2-arg
`KeyLifecycleManager.generateKeyPair(algorithm, keyId)`.
To use any other NIST security level (ML-DSA-44/87, ML-KEM-768/1024, the
SLH-DSA and Falcon variants)
users had to register their own `KeyPair`/`Signature`/`KeyGenerator` beans.
There was no declarative
endpoint option.
## What this does
Adds a **`parameterSpec`** endpoint option (`@UriParam`, label `advanced`).
- **`PQCParameterSpecResolver`** (new) maps an algorithm + parameter-set
name to the BouncyCastle
`AlgorithmParameterSpec`, covering **16 algorithms**: MLDSA, SLHDSA,
FALCON, DILITHIUM, SPHINCSPLUS,
PICNIC, MLKEM, KYBER, NTRU, NTRULPRime, SNTRUPrime, BIKE, HQC, CMCE,
FRODO, SABER.
- **`PQCComponent`** generates the key material with the configured
parameter set instead of the
hardcoded default material, and **caches it per (algorithm,
parameterSpec)** so that endpoints
sharing the same configuration — e.g. a `sign` and a `verify` endpoint —
use the **same key**,
mirroring the semantics of the shared default material. (Without this,
each endpoint would get a
fresh key and verification would fail.)
- **`generateKeyPair`** lifecycle operation now uses the
**parameterSpec-aware** `KeyLifecycleManager`
overload.
### Name handling
Values are BouncyCastle's parameter-set names, resolved
**case-insensitively**; the underscore form of
the BC constants (`ml_dsa_87`) is accepted as an alias of the canonical
`ML-DSA-87`. Note BC is not
uniform here — the modern specs *throw* on an unknown name while the older
ones *return `null`* — both
are normalised into one clear `IllegalArgumentException`.
### Out of scope (rejected with a clear error)
`parameterSpec` is not supported for the **stateful** hash-based signatures
(XMSS, XMSSMT, LMS, HSS),
for **MAYO/SNOVA** (no name-addressable BC parameter spec), nor for the
**hybrid** operations (they pair
a fixed classical key set with a matching PQC key set). Those still use
registry-supplied beans.
## Testing
- `PQCParameterSpecResolverTest` (7 tests): resolves signature and KEM
parameter sets, case-insensitive
and underscore-alias handling, `isSupported`, unsupported-algorithm
rejection, and unknown-name
rejection for **both** the throwing and the `null`-returning BC spec
classes.
- `PQCParameterSpecTest` (6 tests): `parameterSpec` drives the actual key
size (ML-DSA-44 < 65 < 87, and
ML-KEM-512 < 1024), endpoints with the same algorithm+spec **share the
key**, a full sign→verify round
trip with a non-default parameter set, and rejection of XMSS and of hybrid
operations.
All 13 green; full reactor build green (catalog + endpoint-DSL regenerated).
## Documentation
`pqc-component.adoc` gains a *Parameter Sets (NIST Security Levels)* section
with an example, the
key-sharing semantics, a per-algorithm table of parameter-set names, and the
unsupported cases.
## Backport
None — new feature, `main` only (4.22.0).
---
_Claude Code on behalf of Andrea Cosentino._
--
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]
