flexible-transcript already had a shim to support <1.66. This was irrelevant
since flexible-transcript had a MSRV of 1.73. Due to how clunky it was, it has
been removed despite theoretically enabling an even lower MSRV.
Unused and unpublished. This was only added in the FCMP++ branch as a quick fix
for performance reasons. Finding a better API is still a tricky question, but
this API is _bad_.
If a crate has std set, it should enable std for all dependencies in order to
let them properly select which algorithms to use. Some crates fallback to
slower/worse algorithms on no-std.
Also more aggressively sets default-features = false leading to a *10%*
reduction in the amount of crates coordinator builds.
This will effectively add msrv protections to the entire project as almost
everything grabs from these.
Doesn't add msrv to coins as coins/bitcoin is still frozen.
Doesn't add msrv to services since cargo msrv doesn't play nice with anything
importing the runtime.
This is intended to be a reliable transport between the processors and
coordinator. Since it'll be intranet only, it's written as never fail.
Primarily needs testing and a proper ID.
* Partial move to ff 0.13
It turns out the newly released k256 0.12 isn't on ff 0.13, preventing further
work at this time.
* Update all crates to work on ff 0.13
The provided curves still need to be expanded to fit the new API.
* Finish adding dalek-ff-group ff 0.13 constants
* Correct FieldElement::product definition
Also stops exporting macros.
* Test most new parts of ff 0.13
* Additionally test ff-group-tests with BLS12-381 and the pasta curves
We only tested curves from RustCrypto. Now we test a curve offered by zk-crypto,
the group behind ff/group, and the pasta curves, which is by Zcash (though
Zcash developers are also behind zk-crypto).
* Finish Ed448
Fully specifies all constants, passes all tests in ff-group-tests, and finishes moving to ff-0.13.
* Add RustCrypto/elliptic-curves to allowed git repos
Needed due to k256/p256 incorrectly defining product.
* Finish writing ff 0.13 tests
* Add additional comments to dalek
* Further comments
* Update ethereum-serai to ff 0.13
There's two ways which this could be tested.
1) Preprocess not taking in an arbitrary RNG item, yet the relevant bytes
This would be an unsafe level of refactoring, in my opinion.
2) Test random_nonce and test the passed in RNG eventually ends up at
random_nonce.
This takes the latter route, both verifying random_nonce meets the vectors
and that the FROST machine calls random_nonce properly.
The audit recommends checking failure cases for from_bytes,
from_bytes_unechecked, and from_repr. This isn't feasible.
from_bytes is allowed to have non-canonical values. [0xff; 32] may accordingly
be a valid point for non-SEC1-encoded curves.
from_bytes_unchecked doesn't have a defined failure mode, and by name,
unchecked, shouldn't necessarily fail. The audit acknowledges the tests should
test for whatever result is 'appropriate', yet any result which isn't a failure
on a valid element is appropriate.
from_repr must be canonical, yet for a binary field of 2^n where n % 8 == 0, a
[0xff; n / 8] repr would be valid.
