ExpandMsg improvements

[daxpedda]

Changes to ExpandMsg

• Move generic parameter K from ExpandMsg implementers to trait ExpandMsg itself. This was necessary to be able to enforce the correct K instead of letting users insert an arbitrary one. E.g. GroupDigest::hash_from_bytes() can now where X: ExpandMsg<Self::K> instead of users calling hash_from_bytes::<ExpandMsgXmd<Sha256, U0>>().

  However, this made calling ExpandMsg implementers directly more difficult. E.g. instead of ExpandMsgXmd::<Sha256, U32>::expand_msg(...) users now have to write <ExpandMsgXmd<Sha256> as ExpandMsg<U32>>::expand_message(). If we want to address this, I propose adding RawExpandMsgXmd.

• Add CollisionResistance requirement to ExpandMsgXof.

• Move the lifetime on ExpandMsg to the associated type Expander<'dst>.

• Fix dst not actually being checked to be empty, but instead checked for number of slices.

• Move GroupDigests ProjectivePoint: CofactorGroup bound to super trait bounds. This makes it less "poisoning" so downstream users don't have to write where ProjectivePoint: CofactorGroup every time they use GroupDigest.

• Move GroupDigest::hash_to_scalar()s Scalar: FromOkm bounds to GroupDigest. I believe this was a historical leftover when FromOkm wasn't implemented for Scalars yet.

• Improved some documentation around hash2curve and updated all mentions of the draft to RFC9380.

• Rename parameter names msgs and dsts to singular msg and dst. This is to avoid confusion: even though the type is &[&[u8]], it doesn't represent multiple messages or DSTs, but single concated ones.

• Remove non-functioning examples. While I don't think the examples are necessary, I'm happy to re-add them if desired, but I would have to add GroupDigest to the Dev curve.

Changes to VOPRF

While I was at it, I also adjusted a couple of things around VoprfParameters (but I'm happy to split this into its own PR):

• Renamed all mentions of VOPRF to OPRF. VOPRF was the old name of the draft when it was just a single "mode", the RFC is split into three modes: OPRF, VOPRF and POPRF. The RFC itself is called "Oblivious Pseudorandom Functions (OPRFs)".
• Changed associated const ID from &str to &[u8].
• Changed associated type Hash from requiring Digest to Default + FixedOutput + Update.
• Updated all mentions of the VOPRF draft to RFC9497.

---

Related: RustCrypto/hashes#694.
Companion PR: RustCrypto/elliptic-curves#1203.

[daxpedda]

Cc @mikelodder7.

[andrewwhitehead]

Looks good to me.

I was just preparing a PR to address #1146 which would remove the CofactorGroup dependency here. I would propose implementing MapToCurve as in that issue and then simplifying to pub trait GroupDigest: MapToCurve. This would also allow removing the no-op CofactorGroup implementations in the elliptic-curves repo. I could follow up with those changes to avoid conflicts.

[mikelodder7]

This LGTM. I like the approach to remove the poisoning effect.

[daxpedda]

I could follow up with those changes to avoid conflicts.

Feel free to do your thing, I'm happy to rebase.