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.
This saves 4 point doublings by unwrapping the first loop iteration,
as well as 63 field multiplications (one per iteration) by managing
curve model choice explicitly.
See discussion at https://github.com/dalek-cryptography/curve25519-dalek/issues/232 , copied below:
`1.1` changed the trait bounds for `RistrettoPoint::random` and `Scalar::random`, see #222 and #219.
These changes have two benefits:
* they unlink us from the `rand` crate and make us depend only on `rand_core`;
* they allow passing both owned and borrowed RNGs.
The change was not supposed to be a breaking change, since the new bounds are strictly more general than the old ones (as every `RngCore` is an `Rng` and every `&mut RngCore` is an `RngCore`), so the new bound is satisfied in every situation where the old bound applied.
The `1.1.0-pre.0` version didn't cause problems on the crates I tested it on, but there was an unexpected problem: ce71c93a9a/spacesuit/src/value.rs (L160-L161) broke, since it took a borrow as input and used it twice. So there was slight breakage.
One option is to revert the changes (probably just the ones from #219) and release 1.1.3; another would be to fix up `slingshot` and leave the new bound.
Building the docs currently doesn't work, because rustdoc enables parts of the
code (to document them) which then don't check (because there are missing
exports or dependencies). This **should** fix the issue, but there's no way to
test without publishing a new version.
This doesn't (yet) give any speedup over the non-precomputed multiscalar
multiplication, and it's not clear that it's a good idea to commit to
supporting it in the future. Removing it means that it's not committed-to as
part of the public API, but the source is still there in the tree if we want to
revisit it later.
