RFR: 8325448: Hybrid Public Key Encryption [v18]

[Weijun Wang]

On Thu, 1 May 2025 15:06:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   engineGetBlockSize and engineGetOutputSize returns 0 when not initialized
>
> src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 54:
> 
>> 52:         byte[] kemEncap = actual.encapsulation();
>> 53: 
>> 54:         // The HPKE recipient side is initialized with its own private key,
> 
> This is a question, not a comment. How does the recipient know what algorithm identifiers to use? Would these be exchanged as part of a protocol that used HPKE?

I've looked at several protocols that uses HPKE:

1. For (Oblivious DNS over HTTPS)[https://datatracker.ietf.org/doc/html/rfc9230#name-configuration-and-public-ke], server advertises its public keys each in a `ObliviousDoHConfig ` structure with supported algorithm identifiers.
2. For (TLS Encrypted Client Hello)[https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-24#name-encrypted-clienthello-confi], the server advertises its public keys, each with a `kem_id` and a set of supported `kdf_id` and `aead_id`, identified by a `config_id`, in an `ECHConfig` structure. Client will tell server which `config_id` it uses.

So it seems each side chooses the exact algorithm identifiers and even the sender does not require default values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070476759