This was more useful at the time when we were determining, e.g., optimal lookup
table sizes and could regenerate them more easily, but it came at a massive
complexity cost. It also meant that we were unable to implement backend
autoselection. This commit removes the `build.rs` entirely. In the future, a
different `build.rs` could be added that auto-selects a backend, but it seems
like the current default-u64 setup has been working fine.
Closes#238.
This issue was discovered independently by both Jack "str4d" Grigg
(issue #238), who noted that reduction was not performed on addition, and
Laurent Grémy & Nicolas Surbayrole of Quarkslab, who noted that it was possible
to cause an overflow and compute incorrect results.
Found by @3for; this only affected width-7 NAF computations, which were never
used in the source tree (only width 5, optimal for dynamic cases, and 8, better
for static cases).
Closes#272
The function `FieldElement::sqrt_ratio_i` always returns a positive root
by definition. Therefore the test for negativity in the edwards point
decompression function always returns false and we only need to flip its
sign if `compressed_sign_bit` is set.
The NAF computation can generate a 1 in the last digit (only) when s = 2^255-1,
so someone who manually constructed the value s = 2^255-1 and fed it into a NAF-using
computation could generate an incorrect result. Some version of this bug has
been present from the beginning of the library, but it has no security content,
because the NAF computations are not applied to secret data, and the error
occurs only on one value which is not constructed by any client caller.
When using Scalar::from_bits to manually create unreduced Scalars (e.g.,
X/Ed25519 keys with specified bit patterns), it's possible to construct Scalar
values that range up to 2^255-1. These shouldn't ever end up in a vartime
multiscalar mul call anyways, because it doesn't handle secret data, but it is
technically allowed by the type system and should be handled. When w=8, these
can generate terminal carries that can't be folded into the last digit, but
this can be handled by folding them into an extra digit instead.
This fixes a bug in the Pippenger implementation reported by Fernando Krell and
diagnosed by Oleg Andreev. The problem is that at the largest problem sizes
(using w=8), the signed digits fill the value range of an i8, and so doing
computation on them to calculate the bucket index can hit an overflow.
This was not caught in CI because the test suite didn't check all problem
sizes; tests for these sizes which expose this bug were added in the previous
commit.
