Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add kem trait impls when ECDH is supported #1556

Closed
wants to merge 2 commits into from

Conversation

incertia
Copy link

This will allow easy integration of the generic TLS 1.3 KEM combiner, since the current plan is to take any two KEMs that support Encapsulate/Decapsulate and combine them piecewise, and this turns the DH implementations into a KEM as described by TLS. I wonder if this should go into KEMs instead, however.

@tarcieri
Copy link
Member

...KEM as described by TLS.

It would be good to specifically call it out as such, and add test vectors.

I wonder if this should go into KEMs instead, however.

Yes, that'd probably be a good idea. I went ahead and snagged the dhkem crate if you'd like to open a PR there.

@incertia
Copy link
Author

add test vectors.

does this mean adding generic randomized round trip tests or are there test vectors that I'm unaware of?

Yes, that'd probably be a good idea. I went ahead and snagged the dhkem crate if you'd like to open a PR there.

One issue here is that Rust would treat this as an impl of a foreign trait on a foreign type which is forbidden the last time I checked. The impl would have to be proxied. Something along the lines of

struct<X> Proxy(x: X);

impl<C> Encapsulate<EK, SS> for Proxy<EphemeralSecret<C>>
where
    C: CurveArithmetic
{}

which may not be entirely desirable. Let me know what you think.

@incertia
Copy link
Author

The impl would have to be proxied.

One upside here is that we might be able to bundle the DH-KEMs from a variety of providers, probably through an enum?

In particular since X25519-dalek does not implement the elliptic-curve traits to my knowledge, at least one proxy implementation must be written to get X25519Kyber768Draft00 implemented as a generic combiner.

@tarcieri
Copy link
Member

tarcieri commented Apr 17, 2024

The impl would have to be proxied.

Yes, you'd need newtypes for encapsulators/decapsulators.

One upside here is that we might be able to bundle the DH-KEMs from a variety of providers, probably through an enum?

We generally use traits, not enums, to support multiple providers. Enums have a number of drawbacks, such as preventing downstream crates from integrating, and also always linking all of the associated code for all providers whether they're used or not, whereas traits are friendly to dead code elimination.

In particular since X25519-dalek does not implement the elliptic-curve traits to my knowledge

curve25519-dalek supports traits from the group crate, although they're probably only impl'd for EdwardsPoint and not MontgomeryPoint.

That's a problem that could potentially be remedied upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants