RFR: 8325448: Hybrid Public Key Encryption [v10]

Sean Mullan mullan at openjdk.org
Thu Mar 13 18:53:02 UTC 2025


On Wed, 12 Mar 2025 12:18:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to Asserts.assertThrows in test; use traditional javadoc style

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 67:

> 65:  * <a href="https://www.iana.org/assignments/hpke/hpke.xhtml">IANA HPKE page</a>.
> 66:  * <p>
> 67:  * Once an {@code HPKEParameterSpec} object is created, additional methods

Are these additional methods commonly called? If so, did you consider using something like a Builder to avoid the extra object creations?

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 137:

> 135:  * // and the key encapsulation message from the sender
> 136:  * Cipher recipient = Cipher.getInstance("HPKE");
> 137:  * HPKEParameterSpec pr = HPKEParameterSpec.of()

I think it would be useful to give an example with some of the constants.

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 195:

> 193:      * <a href="https://www.rfc-editor.org/rfc/rfc9180.html#name-key-encapsulation-mechanism">Section 7.1 of RFC 9180</a>.
> 194:      */
> 195:     public static final int KEM_DHKEM_P_256_HKDF_SHA256 = 0x10;

Do we really need `KEM_` at the beginning? Seems redundant since `DHKEM` has "KEM" in it. Same comment for the KDF constants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994130149
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994123059
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994117322


More information about the security-dev mailing list