RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]

[Jamil Nimeh]

On Mon, 27 Oct 2025 03:44:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 107:
> 
>> 105:     private static KEM getKEM(String name) throws NoSuchAlgorithmException {
>> 106:         if (APS.isGenericEC(name) || APS.isXDH(name)) {
>> 107:             return KEM.getInstance("DH", DH.PROVIDER);
> 
> May I get more information about the hard-coded provider DH.PROVIDER?  Could it be more general so that other KEM provider can also be used?

the DH provider is there give a KEM-like face on the NIST curves, x25519/448, etc., mainly for the purposes of assisting the work done within the hybrid KEM.  The underlying work being done by the internal DH provider still ends up doing KeyAgreement, KeyPairGenerator and KeyFactory operations, and those should go through the usual provider selection process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2470296043