Exposing FieldElement? about elliptic-curves HOT 6 CLOSED

Thus far we've deliberately avoided exposing field elements in order to provide a misuse resistant API.

For hash2curve specifically my suggestion would be defining traits for hash2curve in the elliptic-curve crate and then implementing them directly in k256/p256.

cc @str4d

from elliptic-curves.

I agree with @tarcieri. I would definitely like to see a hash-to-curve trait (either in group or elliptic-curve) that can provide this functionality, and if the hash-to-field component of the ID proves to be more widely-useful, then a trait to that effect could end up in ff.

from elliptic-curves.

Wouldn't this effectively require implementing SSWU and related logic twice, once for each curve?

from elliptic-curves.

You should be able to define it as e.g. a generic function somewhere like elliptic-curve.

If you're having trouble go ahead and do a copy-and-paste definition for each crate individually and I can take a look at extracting out a generic implementation.

from elliptic-curves.

Another approach that might work for abstracting SSWU would be to define a trait (e.g. Sswu) intended to be impl'd on a curve-specific FieldElement type, which has a map_to_curve_simple_swu function with a default impl and an associated curve-specific const Z.

Then all curve-specific impls of that trait would need to do is define Z.

Something like this perhaps?

pub trait Sswu: // arithmetic bounds go here
{
    const Z: Self;

    fn map_to_curve_simple_swu(&self) -> (Self, Self) {
        ...
    }
}

from elliptic-curves.

Generic optimized SWU has been added upstream to the elliptic-curve crate: RustCrypto/traits#854

from elliptic-curves.