elliptic-curve: naming/future directions for FieldBytes/ScalarBytes/Curve::UInt

[tarcieri]

elliptic-curve v0.10 will now require crypto-bigint as a mandatory dependency, with a Curve::UInt type being how the modulus size of a particular curve's fields are determined, and how a Curve::ORDER constant is stored.

This somewhat eliminates the original need for ScalarBytes<C> (added in #610), which made it possible to ensure a serialized scalar value was in-range when all other crate features weren't enabled. However, as of #649, this type is now how SecretKey<C> is internally represented.

There are now three types with somewhat confusing names and relationships:

FieldBytes<C> is a byte array defined as GenericArray<u8, FieldSize<C>> where FieldSize<C> is <<C as Curve>::UInt as ArrayEncoding>::ByteSize. This is the type which has probably been renamed the most throughout the course of this library's existence. It represents a value which is the minimum-width octet serialization needed to represent both base and scalar field elements, but does not specify which field (it assumes both), and does not ensure the value is in range.

ScalarBytes<C> is a byte array containing a serialized element of the scalar field (represented as FieldBytes<C>), and ensures the value is in range. However, it's confusing there are FieldBytes<C> and ScalarBytes<C>, where the former can contain any value, and the latter maintains an invariant that it represents a valid element of the scalar field.

Curve::UInt is an associated type providing a crypto_bigint::UInt which is large enough to contain elements of either the base or scalar field, but does not check that either are in range.

What's presently lacking is a newtype around Curve::UInt (e.g. FieldElement) which ensures it's in range of a specified modulus. Adding such a type is probably not going to happen before elliptic-curve v0.10 ships.

Open questions:

• Is there a better name we can use for FieldBytes<C>?
• Can ScalarBytes<C> go away, replaced by something (e.g. FieldElement<C>) which contains a Curve::UInt internally?
• Is it possible to provide a common, generic Scalar<C> type that all curve implementations can share?