jdk
jdk copied to clipboard
openjdk
8325448: Hybrid Public Key Encryption
Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
- [ ] Change requires a CSR request matching fixVersion 26 to be approved (needs to be created)
Issue
- JDK-8325448: Hybrid Public Key Encryption (Enhancement - P3)
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411
$ git checkout pull/18411
Update a local copy of the PR:
$ git checkout pull/18411
$ git pull https://git.openjdk.org/jdk.git pull/18411/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 18411
View PR using the GUI difftool:
$ git pr show -t 18411
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18411.diff
Using Webrev
:wave: Welcome back weijun! 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.
![bridgekeeper[bot] avatar](https://avatars.githubusercontent.com/u/41768318?v=4 "Published by a pub.dev verified publisher"){kind=small}
❗ This change is not yet ready to be integrated. See the Progress checklist in the description for automated requirements.
@wangweij 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.
@wangweij This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@wangweij has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@wangweij please create a CSR request for issue JDK-8325448 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.
@wangweij This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@wangweij This pull request has been inactive for more than 16 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.
@wangweij This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
Webrevs
- 12: Full - Incremental (c578ef5d)
- 11: Full - Incremental (25d2fb17)
- 10: Full - Incremental (18e05389)
- 09: Full - Incremental (4bb17504)
- 08: Full - Incremental (9360dfd2)
- 07: Full - Incremental (5b0f319c)
- 06: Full - Incremental (1839c739)
- 05: Full - Incremental (8342e7d4)
- 04: Full - Incremental (92712652)
- 03: Full - Incremental (8ae9a521)
- 02: Full - Incremental (7e525f12)
- 01: Full - Incremental (58773645)
- 00: Full (412efec2)
@wangweij This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.
Initially, I was unsure whether to support mode_auth and mode_auth_psk since our KEM API does not support authenticated encapsulation. However, after looking at HPKE implementations from other vendors -- such as OpenSSL, Go, and Rust -- I found that most of them support it. In the latest commit, I’ve added support by directly invoking newly added methods in the DHKEM private class.
Note that DHKEM is a higher-level cryptographic algorithm built on lower-level primitives like DH key agreement and HKDF. As a result, even though it is implemented only in the SunJCE provider, it can handle keys or IKM values from other providers by leveraging DH and HKDF from those providers.
I've just added a new HPKEParameterSpec::of that only takes KDF and AEAD ids. The reason is that these 2 are really user-choosable and KEM id is usually determined by the key type.
usually determined by the key type.
Hm, might be a bit more complicated for PQ/T Hybrid KEMs. It can of course be added later on, as the implementations using that (like Xwing for HPKE with JOSE) are still in draft state.
We still have the 3-argument of. Also, for future PQ/T Hybrid KEMs, it looks like the trend is that a Hybrid algorithm will have its own KeyPairGenerator (so the user does not need to assemble the key themselves) and the key's algorithm (or parameter set name) will also be its own. So it's quite likely that one key type still has only one kem_id. Let's wait.
I’ve pushed a new commit that allows the sender to retrieve the actual algorithm identifiers used. These identifiers should typically be sent along with the key encapsulation message when establishing an HPKE encryption channel, enabling the receiver to construct the same HPKEParameterSpec to initialize their cipher. This is reflected in the updated example in the class spec.
Furthermore, I almost believe the receiver should not be allowed to initialize an HPKE cipher with an HPKEParameterSpec that has unspecified algorithm identifiers. This becomes especially important if different HPKE implementations have different defaults. What do you think? Please be noted that this means the receiver can no longer initialize a cipher with new IvParameterSpec(encap).
I think I now regret adding the two-argument of method. I'd like to only keep of() which is only for sender, and of(int,int,int) for both sender and receiver.