RFR: 8325448: Hybrid Public Key Encryption [v15]
Weijun Wang
weijun at openjdk.org
Thu Apr 24 22:12:48 UTC 2025
On Mon, 21 Apr 2025 15:24:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>> Consider adding a String or Enum argument to `of()` with the name of the profile, ex "RFC9180".
>
> I can add a sentence saying if an implementation does not provide default numeric algorithm identifiers then an exception will be thrown if `of()` is used by the sender.
>
> I still think it's useful to provide defaults. Now that the recipient requires the numeric algorithm identifiers to be provided, at least this will no longer be an interop issue between implementations. As for future new KEM or KDF algorithms for EC/XDH keys, I believe they will have different numeric algorithm identifiers and users can just specify them so there will be need for "HPKE2".
>
> In fact, suppose the current `kem_id` for XDH is found insecure one day and a new one is defined, we can update the `@implNote` to make the new one the default. Those using `of()` will automatically switch to the safer one and there is no need to update the code. That said, this does need both sides supporting the new `kem_id`.
I’d prefer requiring callers to explicitly specify the three algorithm identifiers rather than introducing profile names. There are several reasons for this:
1. Clarity and consistency: These identifiers are standardized and maintained by IANA in a single registry, making them familiar and unambiguous for all HPKE implementers.
2. Profiles are not precise enough: RFC 9180 allows multiple combinations of algorithm identifiers for a single key type. We'd still need to define what the default is within this profile, which defeats the purpose of using the profile name as a shortcut.
3. Profiles are mainly for new key types: Future profiles will most likely be introduced for new key algorithms (e.g., "RFC9180" for EC/XDH, "draft-connolly-cfrg-xwing-kem" for X-Wing, and "draft-connolly-cfrg-hpke-mlkem" for ML-KEM). Unless a profile defines new combinations for existing key types, it’s not necessary to require users to select among profile names at all. On the other hand, I assume we don’t want to introduce default profiles for key algorithms.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2059310549
More information about the security-dev
mailing list