oscerd opened a new pull request, #29220: URL: https://github.com/apache/camel/pull/29220
Fixes [CAMEL-25824](https://issues.apache.org/jira/browse/CAMEL-25824), raised by @davsclaus while reviewing #28093. ## Problem `hybridGenerateSecretKeyEncapsulation` and `hybridExtractSecretKeyEncapsulation` pass the configured name straight to `HybridKEM`, which uses it to label the `SecretKeySpec` it returns: ```java SecretKey hybridSecretKey = new SecretKeySpec(combinedSecret, symmetricAlgorithm); ``` while `hybridExtractSecretKeyFromEncapsulation` maps it through the enum. For the two algorithms whose configured name is not the JCE name — `DESEDE` → `DESede` and `GOST3412_2015` → `GOST3412-2015` — the two ends of a hybrid exchange therefore disagree on the key's identity, and the label is not a resolvable cipher algorithm, so the key cannot be handed to `Cipher.getInstance(key.getAlgorithm())`. CAMEL-25798 fixed exactly this for the non-hybrid operations; the hybrid ones were missed. ## The part that needed care `HybridKEM` uses that same string **twice**: 1. as the algorithm of the returned `SecretKeySpec` — the label, which should be mapped; 2. as the HKDF `info` of `combineSecrets` — which derives the shared secret itself. Mapping it at the call sites, or blindly throughout, would change the derived key and make **every encapsulation produced by an earlier version undecryptable**. So the mapping is applied inside `HybridKEM`, at the two points where the `SecretKeySpec` is constructed, and nowhere else. The value reaching `combineSecrets` is untouched. `PQCSymmetricAlgorithms` gains `toJceName`, which answers an unrecognised name unchanged rather than throwing, so it is safe to apply to a value that may already be a JCE name. ## Tests New `HybridKEMKeyLabelTest`: - `bothEndsStampTheJceName` — parameterised over `AES`, `DESEDE` and `GOST3412_2015`: both ends carry the JCE name, both still derive the same secret, and the stamped name resolves through `Cipher.getInstance`. - `theDerivedSecretIsUnchangedByTheRelabelling` — deriving with `DESEDE` and with `DESede` must still produce **different** secrets. That is the assertion that proves the HKDF info was left alone: if remapping had leaked into it, these would have become equal and the wire format would have moved. - `anAlreadyJceNameIsLeftAlone` — covers the pass-through behaviour of `toJceName`. Against `main` the first fails with `expected: <DESede> but was: <DESEDE>` and `expected: <GOST3412-2015> but was: <GOST3412_2015>`; `AES` is unaffected, as expected. Full `camel-pqc` build green: 332 tests, 0 failures. ## Upgrade guide Added a 4.24 entry beside its CAMEL-25798 sibling, stating that only the label changes and that the derived key — and therefore compatibility with existing encapsulations — is unchanged. --- _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]
