On Thu, 30 Oct 2025 15:51:29 GMT, Jamil Nimeh <[email protected]> wrote:
>> test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 1: >> >>> 1: /* >> >> Question: does disabling "x25519" also disable "X25519MLKEM768"? It probably >> should not. I think both groups would need to be specified in order to >> disable both. Please add a test for this case. > > 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." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2478726241
