DHKEM from ECDH trait

[jschneider-bensch]

This PR implements an RFC 9180-style DHKEM(X25519, HKDF-SHA256), sans Auth, on top of the ECDH trait in libcrux_curve25519 (only that one, for now).

The implementation is behind a kem-api feature, since users may want to implement their own KEM on top of the ECDH trait, e.g. with a different KDF.

There are some things I'm not quite satisfied with:

• While it is possible to make the arrayref::Kem implementation generic over some const SHARED_SECRET_LEN: usize, it is not possible to make the macro-based implementation of slice::Kem generic. For this reason, I've fixed the SHARED_SECRET_LEN == 32 in both for now.
• The implementation is not really specific to X25519, except for hardcoded (at the moment) KEM identifiers taken from RFC 9180. For this reason, I would really like to avoid duplicating it almost exactly in p256. Some things I've thought about/tried:
  • Blanket impl in libcrux_traits: Does not work because, libcrux_hkdf depends on libcrux_traits via libcrux_sha2. ❌
  • Blanket impl in libcrux_kem: I think this does not work because of the orphan rule, since both traits are foreign. ❌
  • Yet another macro in libcrux_traits::kem: Maybe this could work, but I dislike it, because it makes it harder to understand how things work, and because the macro would have to assume a crate using it has the HKDF dependency, which is not present in libcrux_traits (forbidden there, actually!).❓
• ~I've also had to touch the XWing implementation in libcrux-kem, since it was using the KEM trait API for X25519, assuming it gave you the raw ECDH shared secret. Instead it now uses the ECDH API, which one the one side is what you want to use there. On the other hand the usage of EcdhArrayref is a bit inconvienient I found.~ (Errors handling can also be improved.)

[jschneider-bensch]

Rebased onto jonas/ecdh-keygen to use generate_pair in Xwing.

[keks]

I think the approach here makes sense!

Regarding how to abstract this: Since the blanket impl (had it worked) would likely have lived in libcrux-ecdh, maybe that would be a good place for the impl macro, and then we call it everywhere where we also implement ECDH? I agree it doesn't make this more readable but (a) I don't have an idea for how we could get it to work with blanked impls and (b) at least personally, I don't find macros that much worse than blanket impls from a readability perspective :)

Regarding the extract-then-expand function: Is that exactly one of the HPKE key schedules? Maybe we could call it that.

[jschneider-bensch]

As discussed offline, this doesn't quite go in the right direction. We do want the EC KEMs to output the raw secret for uniformity of use with PQ-KEMs in protocol implementations.

Perhaps this can be salvaged into an easy fix for users that shouldn't use the raw secret, but it's not an immediate priority at the moment.

[github-actions[bot]]

This PR has been marked as stale due to a lack of activity for 60 days. If you believe this pull request is still relevant, please provide an update or comment to keep it open. Otherwise, it will be closed in 7 days.

[github-actions[bot]]

This PR has been closed due to a lack of activity since being marked as stale. If you believe this pull request is still relevant, please reopen it with an update or comment.