Bug: fixed elliptic curve id causes inconsistency with RFC9180 for all curves except P-256

[rot256]

When deriving the KEM key, the wrong info is used for all curves except P-256. The problem is that this:

const HPKE_SUITE_ID: &[u8] = b"KEM\x00\x10";

Should change across curves according to Section 7.1 of RFC9180. I added a bunch of (failing) test vector from the RFC to demonstrate this issue: cargo test -p dhkem --all-features --no-fail-fast.

I also updated some typos referring to an unrelated RFC9810.

[tarcieri]

Were you going to submit a fix for the issue, or just check in the failing test cases?

I'm wondering if perhaps this is a misfeature for this crate, which would be better left to an HPKE implementation instead.

Or failing that, if it can be made more general so it can be used to implement HPKE without having to encode all of this curve-specific logic (though given the crate does include curve-specific features, I guess it could).

[rot256]

I was kinda waiting for you to weigh in, because, as far as I can see, any fix will result in an API/semver break. I'm happy to implement whatever you think is the best way to proceed. I'm inclined to agree that all HPKE related functionality probably belongs in a crate which implements HPKE. Should the expander stuff even stay in the crate?

[tarcieri]

All of the crates in this repo are prereleases and we can still make breaking changes.

I think we should either get rid of the functionality, or make it generic enough we don't need to encode HPKE-specific logic like this.