* WIP constant-time implementation of the ec-divisors library
* Fix misc logic errors in poly.rs
* Remove accidentally committed test statements
* Fix ConstantTimeEq for CoefficientIndex
* Correct the iterations formula
x**3 / (0 y + x**1) would prior be considered indivisible with iterations = 0.
It is divisible however. The amount of iterations should be the amount of
coefficients within the numerator *excluding the coefficient for y**0 x**0*.
* Poly PartialEq, conditional_select_poly which checks poly structure equivalence
If the first passed argument is smaller than the latter, it's padded to the
necessary length.
Also adds code to trim the remainder as the remainder is the value modulo, so
it's very important it remains concise and workable.
* Fix the line function
It selected the case if both were identity before selecting the case if either
were identity, the latter overwriting the former.
* Final fixes re: ct_get
1) Our quotient structure does need to be of size equal to the numerator
entirely to prevent out-of-bounds reads on it
2) We need to get from yx_coefficients if of length >=, so if the length is 1
we can read y_pow=1 from it. If y_pow=0, and its length is 0 so it has no
inner Vecs, we need to fall back with the guard y_pow != 0.
* Add a trim algorithm to lib.rs to prevent Polys from becoming unbearably gigantic
Our Poly algorithm is incredibly leaky. While it presumably should be improved,
we can take advantage of our known structure while constructing divisors (and
the small modulus) to simply trim out the zero coefficients leaked. This
maintains Polys in a manageable size.
* Move constant-time scalar mul gadget divisor creation from dkg to ec-divisors
Anyone creating a divisor for the scalar mul gadget should use constant time
code, so this code should at least be in the EC gadgets crate It's of
non-trivial complexity to deal with otherwise.
* Remove unsafe, cache timing attacks from ec-divisors
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.
* 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
This commit greatly expands the usage of black_box/zeroize on bits, as it
originally should have. It is likely overkill, leading to less efficient
code generation, yet does its best to be comprehensive where comprehensiveness
is extremely annoying to achieve.
In the future, this usage of black_box may be desirable to move to its own
crate.
Credit to @AaronFeickert for identifying the original commit was incomplete.
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.
