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.
Since computation of the 0 term in reduction requires a multiplication with a
4-cycle latency, this ensures that the rest of the computation can start before
the 0 term is finished
This splits the `FieldElement51x4` type into two types:
- `F51x4Reduced` (with reduced limbs)
- `F51x4Unreduced` (with unreduced limbs)
The reduction is implemented as a `From` impl to convert one type to the other.
The output of a multiplication is now a `F51x4Unreduced`. The reason is that
the inputs to IFMA operations must be at most 52 bits, so it's not possible to
perform an addition of (51+epsilon)-bit values and still be small enough to be
used as an input to multiplication. So, it doesn't make sense to perform a
reduction at the end of a multiplication, because the reduced values will be
fed into an addition or subtraction, which then needs to be re-reduced.
This begins to attempt to restructure the source tree so that the common parts
are common and the different parts are different.
The backend is now split into two parts:
- serial (containing the implementation using serial formulas and mixed-model arithmetic).
- vector (containing the implementation using parallel formulas and single-model arithmetic).
The serial scalar_mul tree is now under backend::serial::scalar_mul.
The avx2 scalar_mul tree is now under backend::avx2::scalar_mul.
`FieldElement32` -> `FieldElement2625`
`FieldElement64` -> `FieldElement51`
`Scalar32` -> `Scalar29`
`Scalar64` -> `Scalar52`
This naming is more accurate and would let us add an ADX backend later.
Vicariously updates to `generic-array` 0.12, however this change also
removes `generic-array` as a direct dependency, as it can be sourced
from the `digest` crate.
This partially re-adds functionality removed in commit
d2ce1ce5dc
We would like to require ExactSizeIterator, but unfortunately we can't
do that, since ExactSizeIterators aren't chainable, for (in my opinion)
silly reasons (chaining two 4-billion-element ExactSizeIterators could
overflow on 32-bit systems). Instead we inspect the size hints manually
and assert that the lower and upper bounds are all equal.
This change provides a common convention for using allocator-dependent
features with:
#![cfg(feature = "alloc")]
When available, `Vec` is imported consistently as `prelude::Vec`, which
means modules that need access to `Vec` can simply do:
use prelude::*;
and if an allocator is available, `Vec` will be in the crate prelude.
This allows all `alloc` vs `std` gating to be handled in `lib.rs`,
`build.rs`, and `prelude.rs` so the rest of the codebase doesn't have to
do any gating whatsoever.
