gnodet-bot commented on code in PR #28090: URL: https://github.com/apache/camel/pull/28090#discussion_r4312233925
########## components/camel-pqc/src/test/java/org/apache/camel/component/pqc/crypto/hybrid/HybridKEMCurveTest.java: ########## @@ -0,0 +1,153 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.camel.component.pqc.crypto.hybrid; + +import java.security.KeyPair; +import java.security.KeyPairGenerator; +import java.security.SecureRandom; +import java.security.Security; +import java.security.spec.ECGenParameterSpec; + +import javax.crypto.KeyAgreement; +import javax.crypto.KeyGenerator; +import javax.crypto.SecretKey; + +import org.bouncycastle.jcajce.spec.MLKEMParameterSpec; +import org.bouncycastle.jce.provider.BouncyCastleProvider; +import org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider; +import org.junit.jupiter.api.BeforeAll; +import org.junit.jupiter.api.Test; +import org.junit.jupiter.params.ParameterizedTest; +import org.junit.jupiter.params.provider.CsvSource; + +import static org.junit.jupiter.api.Assertions.assertArrayEquals; +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertThrows; +import static org.junit.jupiter.api.Assertions.assertTrue; + +/** + * The ephemeral key of the classical half must be generated on the curve of the recipient's key. An EC public key + * reports a bare "EC" as its algorithm, so the curve has to come from the key itself. + */ +class HybridKEMCurveTest { + + @BeforeAll + static void setup() { + if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null) { + Security.addProvider(new BouncyCastleProvider()); + } + if (Security.getProvider(BouncyCastlePQCProvider.PROVIDER_NAME) == null) { + Security.addProvider(new BouncyCastlePQCProvider()); + } + } Review Comment: ⚠️ **Missing X25519 test — `XECPublicKey`+`NamedParameterSpec` path uncovered** X448 is covered by `x448RoundTrips()`, but X25519 is not tested at all. The new `generateEphemeralKeyPair` code routes X25519 through the `XECPublicKey instanceof` branch using `NamedParameterSpec` — the same branch as X448. Without a dedicated round-trip test, a regression in that path for X25519 would not be caught. Please add: ```suggestion @Test void x25519RoundTrips() throws Exception { KeyPairGenerator x25519Kpg = KeyPairGenerator.getInstance("X25519", "BC"); KeyPair x25519KeyPair = x25519Kpg.generateKeyPair(); KeyPairGenerator mlkemKpg = KeyPairGenerator.getInstance("ML-KEM", "BC"); mlkemKpg.initialize(MLKEMParameterSpec.ml_kem_768, new SecureRandom()); KeyPair mlkemKeyPair = mlkemKpg.generateKeyPair(); HybridKEM.HybridEncapsulationResult encapResult = HybridKEM.encapsulate( x25519KeyPair.getPublic(), mlkemKeyPair.getPublic(), KeyAgreement.getInstance("X25519", "BC"), KeyGenerator.getInstance("ML-KEM", "BC"), "AES", 256, "HKDF-SHA256"); SecretKey extracted = HybridKEM.extract( encapResult.encapsulation(), x25519KeyPair.getPrivate(), mlkemKeyPair.getPrivate(), KeyAgreement.getInstance("X25519", "BC"), KeyGenerator.getInstance("ML-KEM", "BC"), "AES", 256, "HKDF-SHA256"); assertArrayEquals(encapResult.sharedSecret().getEncoded(), extracted.getEncoded()); } ``` ########## docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc: ########## @@ -212,6 +212,13 @@ also applies to `pollEnrich` and `ConsumerTemplate.receive`, which take one file until the last file of the directory is received, where before the first received file deleted it. This applies to camel-ftp, camel-sftp, camel-smb and camel-azure-files as well. +=== camel-pqc - an unknown hybridKdfAlgorithm is rejected + +The hybrid KEM operations now fail with an `IllegalArgumentException` when `hybridKdfAlgorithm` is not one of +`HKDF-SHA256`, `HKDF-SHA384` or `HKDF-SHA512`. Before, any other value silently fell back to `HKDF-SHA256`, so a typo +such as `HKDF-SHA-512` went unnoticed - and if only one end of an exchange carried the typo, both ends still reported +success while deriving the key with different digests. + === camel-jbang - camel validate normalize writes one file per input file to an output directory `camel validate normalize <files> --output=<dir>` now writes one normalized file per input file into the Review Comment: ⚠️ **Upgrade guide omits the `getBytes` charset fix — add a note** The `info.getBytes()` → `info.getBytes(StandardCharsets.UTF_8)` change is also a wire-format change: on JVMs whose default charset is not UTF-8 (e.g. some IBM platforms or legacy configurations), the HKDF info bytes would differ between old and new code, causing decryption to fail for ciphertexts produced on the old version. In practice `symmetricAlgorithm` is always ASCII (`"AES"`), so all current callers are unaffected — but the change is still technically breaking and should be documented. Suggest adding a sentence to the existing upgrade section, e.g.: > Additionally, the HKDF info bytes are now explicitly encoded as UTF-8 (previously platform default). This has no effect when `symmetricAlgorithm` is `AES` (pure ASCII), but any deployment using a non-UTF-8 JVM default charset would see decryption failures on ciphertexts produced by the previous version. -- 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]
