elliptic-curve: support scalar modulus larger than base field size

[halvors]

secp224k1 has a modulus that is larger than the base field size. This will probably be a big breaking change

[tarcieri]

Right now the size of the base and scalar fields is defined by Curve::FieldBytesSize, and the serialization of both uses FieldBytes<Curve>.

This has worked with every curve up until now.

Supporting this will involve splitting up all of these types. We'd need Curve::BaseFieldSize and Curve::ScalarFieldSize, as well as BaseFieldBytes and ScalarFieldBytes.

This will also particularly complicate the implementation of ECDSA (and similar algorithms like SM2DSA), which need to reduce an element of the base field into the scalar field.

[tarcieri]

Note that in the next breaking release of elliptic-curve we'll be migrating from generic-array to hybrid-array, and I'm a bit wary to try to tackle addressing this issue at the same time as that migration.

Fixing this is going to cause breakage/upgrade pain even though it's irrelevant to most users, so I'm a bit worried about trying to slip it into a release which is otherwise making major breaking changes to the same types.

[halvors]

Note that in the next breaking release of elliptic-curve we'll be migrating from generic-array to hybrid-array, and I'm a bit wary to try to tackle addressing this issue at the same time as that migration.

Fixing this is going to cause breakage/upgrade pain even though it's irrelevant to most users, so I'm a bit worried about trying to slip it into a release which is otherwise making major breaking changes to the same types.

What is the status with the generic-array to hybrid-array, is it complete?

[tarcieri]

As it's a migration which impacts hundreds of crates throughout this project, I'd say we're about halfway through, but there's still a lot of work to go.

The latest prereleases of e.g. p256 make use of it: https://crates.io/crates/p256/0.14.0-pre.0