[
https://issues.apache.org/jira/browse/CAMEL-26549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-26549:
-------------------------------------
Description:
jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
exchange list, but it implements ML-KEM in one of two ways: through the JDK 24+
multi-release classes
({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through Bouncy
Castle ({{com/jcraft/jsch/bc/MLKEM.class}}).
{{camel-ftp}} declares {{bcpg-jdk18on}} and {{bcpkix-jdk18on}} with
{{<scope>test</scope>}}, so on the Java 21 baseline there is no ML-KEM
implementation on the classpath, jsch drops the group from its proposal and the
connection falls back to classical ECDH without a word. The main build runs on
Java 25, where the multi-release path works, so no test catches it.
{{camel-ssh}} is not affected: sshd 2.20 ships {{mlkem768x25519-sha256}},
{{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
{{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, its ML-KEM implementation
is Bouncy Castle based, and camel-ssh has BC at compile scope.
Neither component documents the post-quantum key exchange, nor the
{{keyExchangeProtocols}} (sftp) and {{kex}} (ssh) values needed to pin or
verify it - and a user who pinned {{kex}} years ago is silently stuck on
classical.
was:
jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
exchange list, but it implements ML-KEM in one of two ways: through the JDK 24+
multi-release classes
({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through Bouncy
Castle ({{com/jcraft/jsch/bc/MLKEM.class}}).
{{camel-ftp}} declares {{bcpg-jdk18on}} and {{bcpkix-jdk18on}} with
{{<scope>test</scope>}}, so on a Java 17 or 21 runtime there is no ML-KEM
implementation on the classpath, jsch drops the group from its proposal and the
connection falls back to classical ECDH without a word. The main build runs on
Java 25, where the multi-release path works, so no test catches it.
{{camel-ssh}} is not affected: sshd 2.20 ships {{mlkem768x25519-sha256}},
{{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
{{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, its ML-KEM implementation
is Bouncy Castle based, and camel-ssh has BC at compile scope.
Neither component documents the post-quantum key exchange, nor the
{{keyExchangeProtocols}} (sftp) and {{kex}} (ssh) values needed to pin or
verify it - and a user who pinned {{kex}} years ago is silently stuck on
classical.
Summary: camel-ftp - SFTP cannot negotiate the post-quantum key
exchange on Java 21 because Bouncy Castle is test scoped (was: camel-ftp -
SFTP cannot negotiate the post-quantum key exchange on Java 17 and 21 because
Bouncy Castle is test scoped)
> camel-ftp - SFTP cannot negotiate the post-quantum key exchange on Java 21
> because Bouncy Castle is test scoped
> ---------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26549
> URL: https://issues.apache.org/jira/browse/CAMEL-26549
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
>
> jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
> exchange list, but it implements ML-KEM in one of two ways: through the JDK
> 24+ multi-release classes
> ({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through Bouncy
> Castle ({{com/jcraft/jsch/bc/MLKEM.class}}).
> {{camel-ftp}} declares {{bcpg-jdk18on}} and {{bcpkix-jdk18on}} with
> {{<scope>test</scope>}}, so on the Java 21 baseline there is no ML-KEM
> implementation on the classpath, jsch drops the group from its proposal and
> the connection falls back to classical ECDH without a word. The main build
> runs on Java 25, where the multi-release path works, so no test catches it.
> {{camel-ssh}} is not affected: sshd 2.20 ships {{mlkem768x25519-sha256}},
> {{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
> {{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, its ML-KEM
> implementation is Bouncy Castle based, and camel-ssh has BC at compile scope.
> Neither component documents the post-quantum key exchange, nor the
> {{keyExchangeProtocols}} (sftp) and {{kex}} (ssh) values needed to pin or
> verify it - and a user who pinned {{kex}} years ago is silently stuck on
> classical.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
