👋 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.

❗ 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!

/csr

@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.

/open

@wangweij This pull request is now open

@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

• 22: Full - Incremental (e83a4a1b)
• 21: Full - Incremental (653b56c5)
• 20: Full - Incremental (787702da)
• 19: Full - Incremental (30c79948)
• 18: Full (f819de2e)
• 17: Full - Incremental (a4f59e38)
• 16: Full - Incremental (15d0b85f)
• 15: Full - Incremental (fff8e324)
• 14: Full - Incremental (17dceaa9)
• 13: Full - Incremental (0796a423)
• 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)

Now receiver must provide all algorithm identifiers at cipher initialization. Calling getParameters on sender side returns an AlgorithmParameters object which contains the actual HPKEParameterSpec object used even the key encapsulation message (this message is still retrievable from getIV). In a real world application, the sender would typically retrieve the kem_id, kdf_id, aead_id, key encapsulation message, (optionally) psk_id, and whether an auth-key is used from it, and send these to the receiver. There is no byte array encoding of these information defined yet. Maybe there will be one when HPKE is used in CMS. That said, even if there is one, it probably cannot be used to recover a whole HPKEParameterSpec object directly, as sensitive data like psk and auth-key are not likely to be included.

@wangweij this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8325448
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@wangweij This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command 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 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.

/open

@wangweij This pull request is now open

Mailing list message from Sebastian Stenzel on security-dev:

Hi Weijun,

I?m probably a bit late to the party but nevertheless I hope this finds attention:

To anyone in this mailing list unfamiliar with HPKE: The encapsulation process yields a tuple: A shared secret (the key agreement result, if you will) as well as an encapsulation of said key, that is being sent to the receiver.

Therefore, I don?t think `Cipher` is an appropriate public API for HPKE. The current attempt to make it fit the Cipher API (which can?t return tuples), the encapsulation is received via `cipher.getIV()`. Which is, in my opinion, a misusage and a very confusing one: First of all, `getIV()` returns the ciphertext, usually the result of `doFinal()`. And secondly, as the latter is already used for the shared secret, `getIV()`?s behaviour depends on the state of the Cipher.

Given that HPKE will probably rise in relevance quickly, I strongly advise giving it its own public API that aligns with the spec. Something like this:

```
record Encapsulated(SecretKey sharedSecret, byte[] enc) {}

Encapsulated encap(PublicKey recipientKey);

SecretKey decap(byte[] enc, PrivateKey recipientKey);
```

Best regards,
Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250627/003299ed/smime-0001.p7s>

Hi Sebastian, the API you suggested is only the KEM step, and it should be made internal inside HPKE.

At the end of the day, HPKE is still a cipher. I understand the key encapsulation message (aka, KEM ciphertext) is different from a traditional IV, but they share some key characteristics: 1) generated by the sender after initialization, 2) cryptographically random, 3) then made public, 4) has critical impact on encryption result.

Hi Sebastian, the API you suggested is only the KEM step, and it should be made internal inside HPKE.

At the end of the day, HPKE is still a cipher. I understand the key encapsulation message (aka, KEM ciphertext) is different from a traditional IV, but they share some key characteristics: 1) generated by the sender after initialization, 2) cryptographically random, 3) then made public, 4) has critical impact on encryption result.

I am sorry, I got the names mixed up - too many different standards I was recently reviewing 🙈. Nevertheless, the final result of HPKE is still a tuple, with the encapsulation from the KEM step being required for the receiver to decrypt the message (or "decapsulate" and then "open“, to use the KEM and AEAD wording 😉).

All your points make sense, though. The main difference is, that (so far) all IVs or nonces have to be generated beforehand in order to feed them into the cipher. As opposed to now being a byproduct of the cipher. Maybe I just have to get used to the fact that this doesn’t strictly need to be this way.

It's only a tuple for a single-shot encryption. The general operation is still one encapsulation followed by multiple "seal" outputs. As for the IV, I think it's not uncommon that the cipher generates a random one.