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 > On 27. Jun 2025, at 00:40, Weijun Wang <wei...@openjdk.org> wrote: > >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >>  > > Weijun Wang has updated the pull request incrementally with two additional > commits since the last revision: > > - no more of() > - extract and expand > > ------------- > > Changes: > - all: https://git.openjdk.org/jdk/pull/18411/files > - new: https://git.openjdk.org/jdk/pull/18411/files/f819de2e..30c79948 > > Webrevs: > - full: https://webrevs.openjdk.org/?repo=jdk&pr411&range > - incr: https://webrevs.openjdk.org/?repo=jdk&pr411&range-19 > > Stats: 246 lines in 5 files changed: 23 ins; 178 del; 45 mod > Patch: https://git.openjdk.org/jdk/pull/18411.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 > > PR: https://git.openjdk.org/jdk/pull/18411
smime.p7s
Description: S/MIME cryptographic signature