8314323: TLS 1.3 Hybrid Key Exchange #27614

haimaychao · 2025-10-02T22:52:49Z

Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
Please see JEP 527 for details about this change.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8314323: TLS 1.3 Hybrid Key Exchange (Enhancement - P2)

Contributors

Jamil Nimeh <[email protected]>
Weijun Wang <[email protected]>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614
$ git checkout pull/27614

Update a local copy of the PR:
$ git checkout pull/27614
$ git pull https://git.openjdk.org/jdk.git pull/27614/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27614

View PR using the GUI difftool:
$ git pr show -t 27614

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27614.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-10-02T22:53:45Z

👋 Welcome back hchao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-10-02T22:54:03Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-10-02T22:54:49Z

@haimaychao The following label will be automatically applied to this pull request:

security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

haimaychao · 2025-10-02T22:56:54Z

/contributor add @jnimeh

haimaychao · 2025-10-02T22:57:21Z

/contributor add @wangweij

openjdk · 2025-10-02T22:57:41Z

@haimaychao
Contributor Jamil Nimeh <[email protected]> successfully added.

openjdk · 2025-10-02T22:58:24Z

@haimaychao
Contributor Weijun Wang <[email protected]> successfully added.

mlbridge · 2025-10-03T00:03:19Z

Webrevs

00: Full (c7ba12a7)

artur-oracle · 2025-10-03T14:19:44Z

src/java.base/share/classes/sun/security/ssl/NamedGroup.java

-                algParams.init(keAlgParamSpec);
+                // Skip AlgorithmParameters for KEMs (not supported)
+                if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
+                    if (defaultProviderName == null) {


We assume that if provider is not null then it must be DH without doing any checks to confirm that. It would be cleaner to call getProvider() instead.

Provider p = getProvider();
if (p == null) {
KeyFactory.getInstance(name);
} else {
KeyFactory.getInstance(name, p);
}

artur-oracle · 2025-10-03T16:51:17Z

src/java.base/share/classes/sun/security/util/Hybrid.java

+
+    private static KEM getKEM(String name) throws NoSuchAlgorithmException {
+        if (name.startsWith("secp") || name.equals("X25519") ||
+                name.equals("X448")) {


Do we need X448 here? Also, please provide a comment for this method with functionality description.

artur-oracle · 2025-10-03T16:53:00Z

src/java.base/share/classes/com/sun/crypto/provider/DH.java

+        X25519(32, 32,
+                "XDH", "XDH", NamedParameterSpec.X25519),
+
+        X448(56, 56,


Why do we need X448 and P521?

Need, no. Want, yes. The support for traditional curves that are not part of the first round of hybrid KEMs lays the groundwork for future hybrid KEMs that might use these larger curves. It also gives us the base framework to move these algorithms as named groups to KEM implementations in the future.

I see, thanks for the explanation! I guess it makes sense if we expect those curves to be used in the future rounds of hybrid KEM.

artur-oracle · 2025-10-03T17:22:36Z

src/java.base/share/classes/com/sun/crypto/provider/DH.java

+            implements KEMSpi.EncapsulatorSpi, KEMSpi.DecapsulatorSpi {
+        private final PublicKey pkR;
+        private final PrivateKey skR;
+        private final AlgorithmParameterSpec spec;


This variable is not being used, it can be removed together with the constructor parameter.

ecki · 2025-10-03T17:10:01Z

src/java.base/share/classes/com/sun/crypto/provider/DH.java

+                }
+            } else if (k instanceof XECKey xkey
+                    && xkey.getParams() instanceof NamedParameterSpec ns) {
+                if (ns.getName().equalsIgnoreCase("X25519")) {


Maybe use NamedParameterSpec.X25519?

ecki · 2025-10-03T17:15:33Z

src/java.base/share/classes/sun/security/ssl/NamedGroup.java

            ProtocolVersion.PROTOCOLS_TO_13,
            PredefinedDHParameterSpecs.ffdheParams.get(8192)),

+    ML_KEM_512(0x0200, "MLKEM512",


Are they needed for this Jep?

ecki · 2025-10-03T17:17:57Z

src/java.base/share/classes/sun/security/ssl/NamedGroup.java

        // Finite Field Groups (XDH)
        NAMED_GROUP_XDH("XDH", XDHScheme.instance),

+        NAMED_GROUP_KEM("PQC", KEMScheme.instance),


That Choice of Name needs probably an explaining comment if it is for pure PQC and/ormhybrid?

ecki · 2025-10-03T17:20:04Z

src/java.base/share/classes/sun/security/ssl/NamedGroup.java

            } else {        // default groups
                NamedGroup[] groups = new NamedGroup[] {

+                        // Hybrid key agreements


It feels like all the infra for X448MLKEM1024 is there, so rather than removing x448 from this patch, why not implement it (it’s more obvious than P511 Variants)

Indeed the infrastructure is there, but I don't see an IETF draft that covers that hybrid variant for TLS, nor do I see an IANA mapping for it here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

There needs to be a standard for TLS 1.3 backing these hybrid KEMs before we implement them.

ecki · 2025-10-03T17:20:32Z

src/java.base/share/classes/sun/security/ssl/NamedGroup.java

                        FFDHE_2048,
                        FFDHE_3072,
                        FFDHE_4096,
-                        FFDHE_6144,


Unrelated change?

No, the choise to knock out ffdhe6144 and 8192 from the default list was done on purpose. I don't think they get much use and they can always be re-enabled via SSLParameters or the system property. We're open to feedback on this if you or others feel like they should remain in place, though.

The change is I think ok, doesn’t make much of a difference for most cases I was just thinking it needed its own commit and ticket reference but if it was intentional fine as well.

ecki · 2025-10-03T17:23:37Z

src/java.base/share/classes/sun/security/util/Hybrid.java

+    }
+
+    private static AlgorithmParameterSpec getSpec(String name) {
+        if (name.startsWith("secp")) {


This seems to be repeated multiple times including the case sensitive string, maybe have an APS.isGenericEC() helper?

ecki · 2025-10-03T17:26:01Z

src/java.base/share/classes/sun/security/util/Hybrid.java

+
+        private static int leftPublicLength(String name) {
+            return switch (name.toLowerCase(Locale.ROOT)) {
+                case "secp256r1" -> 65;


Isn’t that Part formte named groups, maybe Look it up instead?

ecki · 2025-10-03T17:27:27Z

src/java.base/share/classes/sun/security/util/Hybrid.java

+
+    private static byte[] concat(byte[]... inputs) {
+        ByteArrayOutputStream o = new ByteArrayOutputStream();
+        Arrays.stream(inputs).forEach(o::writeBytes);


Do we really want a non presized buffer and a stream in the handshake hot path?

haimaychao added 3 commits October 2, 2025 14:53

8314323: TLS 1.3 Hybrid Key Exchange

d5f88bb

Merge

ba5f6f3

8314323: TLS 1.3 Hybrid Key Exchange

c7ba12a

openjdk bot added the security [email protected] label Oct 2, 2025

haimaychao marked this pull request as ready for review October 2, 2025 23:59

openjdk bot added the rfr Pull request is ready for review label Oct 2, 2025

artur-oracle reviewed Oct 3, 2025

View reviewed changes

ecki reviewed Oct 3, 2025

View reviewed changes

8314323: TLS 1.3 Hybrid Key Exchange #27614

Are you sure you want to change the base?

8314323: TLS 1.3 Hybrid Key Exchange #27614

Conversation

haimaychao commented Oct 2, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Oct 2, 2025

Uh oh!

openjdk bot commented Oct 2, 2025

Uh oh!

openjdk bot commented Oct 2, 2025

Uh oh!

haimaychao commented Oct 2, 2025

Uh oh!

haimaychao commented Oct 2, 2025

Uh oh!

openjdk bot commented Oct 2, 2025

Uh oh!

openjdk bot commented Oct 2, 2025

Uh oh!

mlbridge bot commented Oct 3, 2025

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

haimaychao commented Oct 2, 2025 •

edited by openjdk bot

Loading