[ 
https://issues.apache.org/jira/browse/CAMEL-25798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-25798.
---------------------------------
    Resolution: Fixed

Fixed by https://github.com/apache/camel/pull/28093 (merged to main for 4.24.0).

_Claude Code on behalf of davsclaus_

> camel-pqc - generateSecretKeyEncapsulation labels the secret key with the 
> enum name, not the JCE name
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25798
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25798
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-pqc
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.24.0
>
>
> The three KEM operations disagree about which name to stamp on the resulting 
> secret key.
> {{generateEncapsulation}} passes the raw configuration value — 
> {{PQCProducer.java:671-678}}:
> {code:java}
>             generator.init(
>                     new KEMGenerateSpec(
>                             keyPair.getPublic(),
>                             
> getEndpoint().getConfiguration().getSymmetricKeyAlgorithm(),
> {code}
> {{extractEncapsulation}} maps it through the enum — 
> {{PQCProducer.java:700-704}}:
> {code:java}
>                             
> PQCSymmetricAlgorithms.valueOf(getConfiguration().getSymmetricKeyAlgorithm()).getAlgorithm(),
> {code}
> and {{extractSecretKeyFromEncapsulation}} does the same, with a comment 
> stating exactly the rule that {{generateEncapsulation}} breaks — 
> {{PQCProducer.java:723-726}}:
> {code:java}
>         // Use the mapped JCE algorithm name (as extractEncapsulation does), 
> not the raw enum name: for algorithms
>         // whose enum name differs from the JCE name (for example 
> GOST3412_2015 -> GOST3412-2015) the raw name is not a
>         // resolvable cipher algorithm, so the restored key would carry an 
> unusable algorithm label
> {code}
> h3. Which algorithms are affected
> Two of the eighteen constants differ from their JCE name — 
> {{PQCSymmetricAlgorithms.java:32,39}}:
> {code:java}
>     GOST3412_2015("GOST3412-2015"),
>     DESEDE("DESede");
> {code}
> So for those two the generate side emits a {{SecretKeyWithEncapsulation}} 
> whose {{getAlgorithm()}} is {{DESEDE}} / {{GOST3412_2015}} while the extract 
> side emits {{DESede}} / {{GOST3412-2015}}. The generate-side label is not a 
> resolvable cipher name, so handing that key to 
> {{Cipher.getInstance(key.getAlgorithm())}} or to {{CryptoDataFormat}} fails, 
> and the two ends of one KEM exchange disagree about the key's identity.
> h3. Existing tests encode both answers
> {{PQCMLKEMGenerateEncapsulationCryptoRoundTripDESedeTest.java:96-97}} asserts 
> the wrong one:
> {code:java}
>         assertEquals("DESEDE",
>                 
> resultEncapsulate.getExchanges().get(0).getMessage().getBody(SecretKeyWithEncapsulation.class).getAlgorithm());
> {code}
> while {{PQCExtractSecretKeyAlgorithmNameTest.java:126}} asserts 
> {{assertEquals("DESede", restored.getAlgorithm());}} for the same configured 
> algorithm. The first test needs updating with the fix.
> h3. Related: a missing guard on the same method
> Both extract operations reject an empty {{symmetricKeyAlgorithm}} — 
> {{PQCProducer.java:693-695}}:
> {code:java}
>         if 
> (ObjectHelper.isEmpty(getConfiguration().getSymmetricKeyAlgorithm())) {
>             throw new IllegalArgumentException("Symmetric Algorithm needs to 
> be specified");
>         }
> {code}
> and both hybrid KEM paths guard it too ({{:834-836}}, {{:878-880}}). 
> {{generateEncapsulation}} ({{:667-685}}) is the single unguarded sibling and 
> passes the possibly-null value straight into {{new KEMGenerateSpec(...)}}. 
> {{validateSymmetricKeyLength}} does not cover it either — it returns early 
> when the algorithm is empty ({{:1241-1243}}).
> h3. Suggested fix
> Use {{PQCSymmetricAlgorithms.valueOf(...).getAlgorithm()}} in 
> {{generateEncapsulation}}, add the missing guard, update the DESede test, and 
> add a test that asserts the generate-side and extract-side {{getAlgorithm()}} 
> agree (no GOST3412_2015 round-trip exists at all today).
> ----
> _Reported by Claude Code (AI agent) on behalf of [~oscerd]. Every code 
> reference was verified against commit {{7aae27315946}} on {{main}}._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to