Unfortunately, Rust selects `i32` as the type for an integer literal
when the literal has no other type constraints. This means that someone
cannot write `Scalar::from(1)`, as Rust will choose `i32` as the type for
`1`, and we don't `impl From<i32> for Scalar`.
We could implement `From` conversions for signed integers, but since
`Scalar` operations should be constant-time by default, this would
require us to extract the sign bit of the integer and use it to
conditionally select between the positive and negative of Scalar
constructed from the value bits. This is more expensive than the
unsigned operation, and I don't think it's what anyone really wants.
Making API consumers specify that their literals are unsigned is
slightly annoying, but better than the above alternative.
It would also be nice to change `Scalar::from_hash` to be
`impl<D: Digest<OutputSize = U64>> From<D> for Scalar`,
but this isn't currently allowed by Rust (since that `impl` "could"
conflict with the `impl From<u8>` if someone decided that `u8` should
`impl Digest`).
This changes the primary function for the `VartimeMultiscalarMul` trait
to an `optional_multiscalar_mul` trait that accepts
`Option<Self::Point>` (and returns `None` if any input points are
`None`).
The existing `vartime_multiscalar_mul` is changed to be a wrapper around
this function to avoid code duplication. This may result in an
extra copy of each input point, but that cost is probably not
significant compared to the cost of the multiscalar multiplication.
The motivation is to allow performing multiscalar multiplications with
inline decompression. Currently, API consumers have to allocate
temporary buffers for all of their points, decompress into those
buffers, then pass (iterators over) those buffers into the multiscalar
multiplication code, which then creates new buffers for lookup tables.
These traits have the same interface, but with different names, so that it's
not possible to use them interchangeably. (Constant-time and variable-time
routines should not be used interchangeably).
This commit changes the external API to use these traits, replacing
```
edwards::multiscalar_mul
edwards::vartime::multiscalar_mul
```
with
```
EdwardsPoint::multiscalar_mul (as an impl)
EdwardsPoint::vartime_multiscalar_mul (as an impl)
```
and similarly for Ristretto.
Refactoring the backend is for a later commit.
Multiscalar multiplication with precomputation is for a later commit.
The `edwards::vartime` module is retained since it's used for
`vartime_double_base_scalar_mul`.
It should be subsumed into the precomputation API in a later commit.
Each backend can now be selected by an individual feature:
- `u32_backend` for `backend::u32`;
- `u64_backend` for `backend::u64`;
- `avx2_backend` for `backend::avx2`;
The `u64_backend` is selected by default, since most people use X64 and we have
no way to select based on target (see discussion in #126). However, these
changes mean that it is possible to select the backend explicitly, and if we
had the ability to select target-default features, we could do so easily.
When building on stable, the README.md is not included in the documentation,
leaving a bare entry. This adds a warning stub, pointing people to use nightly
rust.
Change Scalar::non_adjacent_form() to take a width parameter.
This rewrite also makes it faster, although it's probably a ways off
from optimal. I don't know how much it matters.
TODO: write up description of why this computes the same thing.
Thanks to @oleganza for pointing out an error reading bits across words
in an earlier version of this code.
This change required some work, because the to-be-stabilized SIMD functions
don't allow non-constant `imm8`s. Previously, the `stdsimd` functions had a
constifying macro that ensured that the immediates were known. The dalek code
used this to build helper functions which would be inlined into different
places where the immediates were known. Unfortunately, since constexprs aren't
fully supported in Rust yet, this is done by a hidden compiler attribute, and
there's no way to propagate "constness".
To deal with this, some of the functions are specialized (e.g.,
`square_and_negate_D` instead of taking a mask), and others use an enum.
