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.
This should contain generic implementations of scalar multiplication algorithms
that can be used with multiple backends. The goal is to move the existing
scalar multiplication code into this submodule, then call it from the
user-facing API. This can also contain code for things we can't do now, like
multiscalar multiplication with precomputation.
Since Criterion can only benchmark public API, these changes just drop
all internal benchmarks (e.g., benchmarks for field operations). But
those are usually microbenchmarks whose meaning is kind of questionable
anyways, so I don't think this is a big loss.
The `bench` feature disappears, since Criterion works on stable Rust.
The public-facing types with arithmetic operations are:
- `Scalar`s
- `ExtendedPoint`s
- `RistrettoPoint`s
For these types we define operators with all combinations of borrowed and
non-borrowed inputs, to avoid forcing API consumers to write extra ampersands.
Since all of the operations involved with these types are expensive relative to
the cost of an unnecessary copy, this isn't a big deal.
The `MontgomeryPoint` struct isn't included in the above because it's only
useful for scalar multiplication.
This commit is based on work by @UnlawfulMonad.
This reverts commit 804dab8924, reversing
changes made to 5d15ca77ff.
This is due to a (previously undocumented) contract on the behaviours of
(potentially unreduced mod \ell) "packed" scalars w.r.t. to the manner in which
their bytes are interpreted.
Upon documentation fixes and corresponding fixes being made on top of the
floodyberry/optimized_scalar branch, this revert will again be reverted and then
the additional changes merged (à la
file:///usr/share/doc/git/html/howto/revert-a-faulty-merge.html).
Signed-off-by: Isis Lovecruft <isis@patternsinthevoid.net>
Split the field arithmetic implementations into `FieldElement`,
`FieldElement32`, and `FieldElement64`. `FieldElement` is a type alias for one
of `FieldElement32` or `FieldElement64`, depending on feature selection.
`field.rs` contains tests and code which is generic with respect to the
implementation (e.g., inversions), while `field_32bit.rs` and `field_64bit.rs`
contain the implementation-specific code.
The implementation is not completely hidden, since `FieldElement32` and
`FieldElement64` are tuple structs whose elements are public; `pub(crate)`
doesn't seem to work for tuple structs.
Similarly, the constants file is split over multiple files, depending on the
implementation.
libcollections was recently merged into liballoc:
https://github.com/rust-lang/rust/pull/42648
I went ahead and also added an "alloc" feature which no_std users can use to opt
into liballoc features (i.e. any code using Vec). This should have no effect on
anything but no_std usage. It does make it possible for people without
allocators to use curve25519-dalek if they want though. Might be nice for
"bare metal" development.
All that said, from what I can gather liballoc, while not "stable", should
likely stick around for the forseeable future.
Some backstory on the liballoc/libcollections merge here:
https://github.com/rust-lang/rust/pull/42565
