oscerd opened a new pull request, #24678:
URL: https://github.com/apache/camel/pull/24678
# CAMEL-23844: Camel-PQC — use the mapped JCE algorithm name when restoring
the secret key
## The bug
`PQCProducer.extractSecretKeyFromEncapsulation()` built the restored key as:
```java
new SecretKeySpec(payload.getEncoded(),
getConfiguration().getSymmetricKeyAlgorithm())
```
That passes the **raw `PQCSymmetricAlgorithms` enum name** as the
`SecretKeySpec` algorithm, whereas
`extractEncapsulation()` correctly maps it via
`PQCSymmetricAlgorithms.valueOf(...).getAlgorithm()`.
Only two enum names differ from their JCE names, and the impact is very
different for each:
| Enum name | JCE name | `Cipher.getInstance(<enum name>)` |
|---|---|---|
| `DESEDE` | `DESede` | **OK** — JCA lookup is case-insensitive |
| `GOST3412_2015` | `GOST3412-2015` | **`NoSuchAlgorithmException`** —
underscore is not a valid JCE name |
So for **GOST3412_2015** the secret key handed back to the route carried an
algorithm label that
cannot be resolved to a cipher at all, making the restored key unusable
downstream (verified against
BouncyCastle 1.85).
The existing KEM round-trip tests do not catch this because they encrypt
with an explicitly configured
`CryptoDataFormat("DESede")` and never read the key's own label.
## The fix
Use
`PQCSymmetricAlgorithms.valueOf(getConfiguration().getSymmetricKeyAlgorithm()).getAlgorithm()`
—
the same mapping `extractEncapsulation()` already uses — in **both** extract
paths:
`extractSecretKeyFromEncapsulation` and
`hybridExtractSecretKeyFromEncapsulation`.
## Testing
New `PQCExtractSecretKeyAlgorithmNameTest` (2 tests) runs a full
generate → extract → extract-secret-key route and asserts the restored key's
algorithm is the **JCE**
name, and that `Cipher.getInstance(key.getAlgorithm())` resolves.
Verified it is a true regression test — **without** the fix it fails with:
```
expected: <GOST3412-2015> but was: <GOST3412_2015>
expected: <DESede> but was: <DESEDE>
```
All 17 existing KEM round-trip tests still pass. Full reactor build green.
## Note for reviewers (not changed here)
`generateEncapsulation()` passes the same **raw** enum name into
`KEMGenerateSpec`, so the
`SecretKeyWithEncapsulation` it produces is labelled `GOST3412_2015` /
`DESEDE` too. I deliberately left
that alone: the name there is only a label (it is not part of the KEM
derivation — generate and extract
already disagree today and the round trip still works), and changing it
would alter a **visible** output
label and require updating existing test assertions. Happy to align it in a
follow-up if you'd prefer
full consistency.
## Backport
This is a bug → **4.18.x (4.18.4)** and **4.14.x (4.14.9)**. On those
branches only the standard extract
path exists (the hybrid operations came later), so the backport is the
single-line fix plus the test.
---
_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]
