Implement GroupDigest for NistP256 and Secp256k1

[daxpedda]

See RustCrypto/traits#865.
This replaces #495 where I copied some code from @mikelodder7. The reason I did that is to test changes, for example, for RustCrypto/traits#871.

Currently builds on top of RustCrypto/traits#876.

[mikelodder7]

I’d like to not have to copy osswu into k256. I’ve got it working locally with only those two changes

[daxpedda]

I agree, we will need to fix this in elliptic-curve.

EDIT: with the two changes you mean adding normalize inside the OSSWU implementation in elliptic-curve, yes?

[daxpedda]

I copied these test vectors from the VOPRF spec, I don't know any other spec providing test vectors for hash_to_scalar. The VOPRF spec also doesn't define any for k256.

[mikelodder7]

I'm happy to move my other PR which implements all the hash2curve to something similar to this unless you are planning to turn this into a regular PR. Thoughts?

[daxpedda]

The plan is to turn this into a regular PR actually, I just can't until a new version of elliptic-curve is released. So as soon as that's done I'm going to update this.

[daxpedda]

I can't make sense of this error. infinity should be a Choice, not a u8.

    Checking k256 v0.10.1 (/home/runner/work/elliptic-curves/elliptic-curves/k256)
error[E0308]: mismatched types
   --> k256/src/arithmetic/hash2curve.rs:144:23
    |
144 |             infinity: Choice::from(0u8),
    |                       ^^^^^^^^^^^^^^^^^ expected `u8`, found struct `elliptic_curve::subtle::Choice`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `k256` due to previous error

[tarcieri]

@daxpedda that was a recent change (#511) which was needed to allow an inherent constants for IDENTITY and GENERATOR, since Choice can't be used in a const context

[daxpedda]

Thanks, this should be good to go now.

[daxpedda]

I noticed when removing the sgn0 method and internally using is_odd instead, it complained that it wasn't normalized. Does that look alright @mikelodder7?

[daxpedda]

elliptic-curves/k256/src/arithmetic/field/field_impl.rs

Lines 91 to 94 in 8a44a3f

	pub fn is_odd(&self) -> Choice {
	debug_assert!(self.normalized);
	self.value.is_odd()
	}

[tarcieri]

@fjarri do you think is_odd should call normalize first?

[mikelodder7]

Anytime comparisons are used for osswu it has to be normalized otherwise it gets wrong results

[fjarri]

Yes, I would assume you need to normalize, since the modulus is odd, so x and x+modulus (possible even if you have magnitude=1, but not normalized) will have different parity.

[daxpedda]

Alright, will change is_odd to normalize first then.

[daxpedda]

Done.

[daxpedda]

Re-based because of #506.