On Thu, 30 Oct 2025 16:18:11 GMT, Jamil Nimeh <[email protected]> wrote:
>> It might depend on which level we're disabling things at. If we're talking >> about knocking out x25519 in the namedGroups property then no, it won't >> disable the hybrid. The client will just choose a different key share to >> use with X25519MLKEM768 in the initial client hello. I know I've tried >> knocking out x25519 as a disabled algorithm in the past and I believe it >> will knock out the hybrid as well since the lower-level KeyAgreement >> operation in the DH provider that the hybrid uses should be blocked. I can >> test that again to make sure my memory is correct on that point. > > Update: I was only half-right. Via the `jdk.tls.namedGroups` property or > SSLParameters, each named group stands on its own. You can add or remove > them without impacting the others. When I took `x25519` out, it sent > `X25519MLKEM768` and `secp256r1` key shares in the initial client hello. > > Adding `x25519` to java.security (`jdk.tls.disabledAlgorithms`) does not > prevent a hybrid with that component from functioning. I just tested that a > few moments ago. I went back through some notes from a few months ago and I > had that behavior documented there as well. > > That seems consistent with what we say in the JEP about hybrid schemes: "... > and is secure as long as one of the algorithms remains unbroken." Good, the latter behavior was what I was questioning and I agree that is the way it should work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2478759010
