On Fri, 27 Jun 2025 15:46:24 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-3014187394
