-
Notifications
You must be signed in to change notification settings - Fork 177
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
elliptic-curve: hash-to-curve support #481
Comments
I'd expect some churn coming based upon https://mailarchive.ietf.org/arch/msg/cfrg/ZYlKNd4JJiJxNTYSwrY-ZFb4LeI/ |
I think we can potentially work on some hash-to-curve traits while the spec is still in flux.
|
As discussed in #481, this removes the `FromDigest` trait, and with it any dependency on the `digest` crate (at least for now). The reasoning is `FromDigest` in its current form exists to solve a single concern: hash-to-scalar for the specific purposes of ECDSA, which is implemented in the `k256` and `p256` crates as a "narrow" reduction per the requirements of ECDSA. Given that, this trait is best moved to the `ecdsa` crate, clearing the way for a move generally useful, well-considered, and well-specified and standardized hash-to-curve construction as requested in #481. The plan after this is to provide an identical trait, but in the `ecdsa` crate instead of the `elliptic-curve` crate.
As discussed in #481, this removes the `FromDigest` trait, and with it any dependency on the `digest` crate (at least for now). The reasoning is `FromDigest` in its current form exists to solve a single concern: hash-to-scalar for the specific purposes of ECDSA, which is implemented in the `k256` and `p256` crates as a "narrow" reduction per the requirements of ECDSA. Given that, this trait is best moved to the `ecdsa` crate, clearing the way for a move generally useful, well-considered, and well-specified and standardized hash-to-curve construction as requested in #481. The plan after this is to provide an identical trait, but in the `ecdsa` crate instead of the `elliptic-curve` crate.
As discussed in #481, this removes the `FromDigest` trait, and with it any dependency on the `digest` crate (at least for now). The reasoning is `FromDigest` in its current form exists to solve a single concern: hash-to-scalar for the specific purposes of ECDSA, which is implemented in the `k256` and `p256` crates as a "narrow" reduction per the requirements of ECDSA. Given that, this trait is best moved to the `ecdsa` crate, clearing the way for a move generally useful, well-considered, and well-specified and standardized hash-to-curve construction as requested in #481. The plan after this is to provide an identical trait, but in the `ecdsa` crate instead of the `elliptic-curve` crate.
Adds the `FromDigest` trait, originally from the `elliptic-curve` crate: RustCrypto/traits#532 Since this trait implements ECDSA-specific concerns, it was removed from the `elliptic-curve` crate in the above PR to make room for things like hash-to-curve constructions. See: RustCrypto/traits#481
Adds the `FromDigest` trait, originally from the `elliptic-curve` crate: RustCrypto/traits#532 Since this trait implements ECDSA-specific concerns, it was removed from the `elliptic-curve` crate in the above PR to make room for things like hash-to-curve constructions. See: RustCrypto/traits#481
Adds the `FromDigest` trait, originally from the `elliptic-curve` crate: RustCrypto/traits#532 Since this trait implements ECDSA-specific concerns, it was removed from the `elliptic-curve` crate in the above PR to make room for things like hash-to-curve constructions. See: RustCrypto/traits#481
Here's a library that implements It provides an example for using it with cc @mikelodder7 |
I'm also working on crates for the optimized swu map and isogeny map if that helps. The idea is I've implemented hash2curve so many times and in |
Continuation of this discussion: RustCrypto/elliptic-curves#432 (comment)
I am not sure I see a problem (though I can't say I 100% understand your snippet). |
Looking at this gist again: https://play.rust-lang.org/?gist=6547bf4c636d51196326fd26aa4bbdee ...it seems pretty problematic that the scalar type is parameterized by a
The main bound I need for ECDSA is this one: Scalar<C>: FromDigest<FieldSize<C>> I want to express that a particular scalar type impls |
This is why I wrote that this trait probably should be implemented by a wrapper. I do agree that it's worth to keep
Then write this constraint directly as I've done it in the snippet using the |
I don't understand how to express that, and as a general comment I find those trait bounds extremely hard to read. |
The primary rationale for that is a misuse-resistant API which upholds the requirements of e.g. the Fiat-Shamir heuristic. See: |
I would consider the hash-to-scalar case mostly addressed by the introduction of a The larger remaining issue is hashing to elliptic curve points ala Perhaps we could look to something like @mikelodder7's aforementioned |
The The impl is currently behind an experimental feature flag, both in case the ID changes, and because we wanted feedback on the trait design. I'd be happy to help uplift (something like) those traits into either |
Just linking the current progress so people can chime in on their needs:
And the actual implementation on curves: |
I guess this can be closed now? Just waiting for a new release. |
I can cut a release, but please keep in mind that once I do all features are stable until the next breaking release. Are you ready for that? Alternatively we can try to land the PRs to https://github.com/RustCrypto/elliptic-curves first (using a |
I didn't actually mean to ask for a release, but it would actually be great. I already tried the API for the projects I'm working on, so as far as I'm concerned the API is fine. I noticed a small thing that could be improved that I will PR for.
Why? What do you have in mind we would gain from doing that first? |
If you're happy with the API, then I can go ahead and cut a release. @mikelodder7 are you ok with that? |
See #881. Otherwise I'm good to go. |
Yes I’m happy with where we’ve landed |
I think we're good to go here now |
It would be nice to have support for a
from_uniform_bytes
functionality for the elliptic curve implementations that performs the hash-to-curve operations described here, preferably the_SSWU_RO_
variants!The text was updated successfully, but these errors were encountered: