Upgrade to HPKE v0.14

[rozbb]

Making this to start the conversation about how to upgrade. Right now it's the absolute minimum possible diff to do the upgrade. But I suspect you might want to change your own feature flags to match the new ones upstream, and also maybe add some to expose the new PQ and hybrid ciphersuites. Let me know what you're thinking

[tgeoghegan]

Thanks for the PR, Michael.

IMO this crate's goal is just to be an adapter to hpke that allows runtime dispatch. If we introduce any abstractions on top of hpke, like a different set of features, we're doing a disservice to users by getting in the way of what they really want to do. So what I mean by all that is: we should harmonize hpke-dispatch's features with hpke.

We will also need to update the discussion of features in README.md before merging.

And wiring up PQ and hybrid HPKE is worthwhile.

[rozbb]

Great, I can make those changes 👍

[tgeoghegan]

Thanks, but let's see if @jcjones or @divergentdave have an opinion to share before we make another move.

[divergentdave]

Mirroring hpke's features and forwarding them sounds good. Our existing per-algorithm features may have gone a bit overboard.

[rozbb]

Aligned features and added new KEMs and KDFs. Lmk if there's anything else you'd like. I realized that I'm missing MLKEM-512. I'll add that in a future version. I'm not in much of a rush

[rozbb]

One question: is it necessary to feature-gate base_mode_open/base_mode_seal? What's the reason to omit those?

[tgeoghegan]

Thanks, Michael.

IMO we should align our feature flags as much as possible with hpke so that we're as unsurprising as possible. To that end, I think we should remove the aead-, kdf- and kem- prefixes.

One question: is it necessary to feature-gate base_mode_open/base_mode_seal? What's the reason to omit those?

It doesn't seem useful to omit these, especially since users of hpke-dispatch pull in hpke no matter what. I think we should take the opportunity to remove these features.

I pushed a commit that does the above two things, as well as updating README.md and cleaning up some doccomments.

Separately from this PR, we should extend tests/test_vectors.json to include test cases for PQ and hybrid combiners: #110

[tgeoghegan]

I changed my mind: adding the PQ test vectors is so easy that I think we can just do it here. It's only a few lines of code, plus 122 kB of JSON imported from hpke-pq.

[divergentdave]

The feature list at the end of the README is now ["aes", "hkdfsha2", "nistp", "serde"]

[divergentdave]

I think these are just defined in FIPS 202

[divergentdave]

We should still reference RFC 9861 for TurboSHAKE128 and TurboSHAKE256

[tgeoghegan]

Merged -- thank you for the contribution, @rozbb, as well as your continued hard work on HPKE!