wNAF uses `PrimeField::to_repr` on scalars assuming little endian

[tarcieri]

Several places in wnaf.rs, PrimeField::to_repr is called on scalars assuming this outputs a little endian serialization. That method is documented as follows:

/// The endianness of the byte representation is implementation-specific. Generic
/// encodings of field elements should be treated as opaque.

We are using the big endian SEC1 serialization of scalars for our implementations of the NIST P-curves as well as secp256k1.

It would be nice to eliminate the endianness assumptions in the implementation. As a hack we added a secondary method which always provides a little endian serialization to PrimeField in rustcrypto-ff, but whatever can eliminate the endianness assumptions here would be nice. Perhaps something that constructs an Iterator over the bits of the scalar in little endian order would be generally useful?

[ebfull]

Possibly allow the implementor to choose the "native" endianness for their PrimeField type, specified in an associated const, and force the callers to deal with it by forcing the endianness to appear in the result of the representation type (as a wrapper). Callers can grab the underlying bytes and work with the type's specified endianness, or utility functions (iterators) that are agnostic to the endianness. We can provide these.

I think we wanted to be opinionated about the endianness initially to avoid this conversation entirely, forcing consumers of the API to put their own encoding/serialization facade over the concrete PrimeField types (which we didn't expect to be exposed directly in those code paths anyway).

[tarcieri]

@ebfull would you be okay with an additive change to ff for that perhaps, e.g. pub trait FieldEndianness with an associated pub enum ByteOrder constant?

I ask because I already have an enum like that in the primefield crate (which only depends on ff, not group) and it would be nice to be able to source that enum from ff if it's defining one, and also there may be other field element applications that could use that information (we use it in primefield, for example).

If that sounds good I can write an RFC for it.

[ebfull]

@tarcieri Sure, though PrimeField should probably just require the ByteOrder associated constant right? (If it has endian-sensitive APIs in it, then it seems like it shouldn't be another trait.)

[tarcieri]

Yes, though that'd be a breaking change, right? I'd be fine with that if you want to make a last minute one and yank ff v0.14.0

[tarcieri]

Never mind, it can be done purely additively using an associated constant default: https://github.com/RustCrypto/ff/pull/14

I'll go ahead and write up an RFC for this.

[tarcieri]

I've opened an RFC which proposes to add a pub enum ReprEndianness to ff, and an associated constant thereof on PrimeField, all of which can be done in a purely additive manner: zkcrypto/rfcs#4