* Remove dependency on `packed_simd`
* Support SIMD on stable Rust
* Move `packed_simd.rs` to `vector` module
* Add comment header to `packed_simd.rs`
* Initialize SIMD registers using intrinsics instead of `transmute`
* Use a splat inside of `unpack_pair`
* Update README: the AVX2 backend now works on stable Rust
* Add a CI job to also build the AVX2 SIMD backend on Rust stable
* Added SIMD MSRV test
* Removed Scalar::{from_bits, from_bytes_clamped}; all constructible scalars are now reduced mod l
* Made Scalar::reduce() not pub; fixed test warning
* Added benches for scalar add/sub/mul
* Docs
* Added EdwardsPoint::mul_base_clamped and gated Scalar::from_bits behind legacy_compatibility
* Added unit test for Mul impl on unreduced Scalars
* Added Montgomery::mul_base_clamped
* Added BasepointTable::mul_base_clamped
* Removed invalid scalar arithmetic test; this functionality is no longer supported
* Made clamp_integer() const
* Updated readme and changelog
* Added BasepointTable::mul_base_clamped to tests
* Added proper deprecation notice to Scalar::from_bits; added legacy_compatibility to Makefile and docsrs flags
* Fixes cfg with target from env
* Derive cleanup
* Default to curve25519_dalek_bits="32" on unknown target
* Give out warning (thanks @jcape)
Co-authored-by: ryan <ryankurte@users.noreply.github.com>
Co-authored-by: James Cape <james@mobilecoin.com>
* Fixed-based Montgomery scalar multiplication
Adds `MontgomeryPoint::mul_base` as an API for fixed-base scalar
multiplication which allows for potential future optimizations.
As a baseline implementation, it uses the variable base scalar
multiplication implementation.
This follows the existing `EdwardsPoint::mul_base` and
`RistrettoPoint::mul_base` APIs.
* Added Montgomery mul_base bench
* Switched MontgomeryPoint::mul_base to use EdwardsPoint::mul_base
---------
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
Re-exports the following commonly used types from their respective
modules to the toplevel of the crate, which makes them easier to access:
- `EdwardsPoint`
- `MontgomeryPoint`
- `RistrettoPoint`
- `Scalar`
The `from_slice` methods on `CompressedEdwardsY` and
`CompressedRistretto` both previously panicked if the slice was the
wrong length.
This changes them to be fallible, returning `TryFromSliceError` in the
event the slice is the wrong length.
It also adds a `TryFrom<&[u8]>` impl for each of these types which calls
the corresponding `from_slice` method.
This is the name we adopted for a similar feature in @RustCrypto.
It's a bit less jargony and also leaves the door open in the future to
other types of precomputed tables.
* Add `basepoint-tables` crate feature
Feature-gates the inclusion of basepoint tables under a
`basepoint-tables` feature, with the goal of reducing code size for e.g.
embedded applications.
* Add `mul_base` method to `EdwardsPoint` and `RistrettoPoint`
Provides fixed-base scalar multiplication which optionally uses
precomputed basepoint tables when the `basepoint-tables` feature is
enabled, providing 4X better performance.
Falls back on variable-base scalar multiplication in the event the
feature is disabled.
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
* Make basepoint table constants static references
This ensures they have a fixed address and aren't duplicated across
compilation units.
Since they were already always borrowed, this changes the static values
to be `&'static` addresses to ensure they're always borrowed rather than
potentially copied.
* rustfmt
The recommendation to set this has been removed from the Rust API
guidelines:
https://github.com/rust-lang/api-guidelines/pull/230
It used to be used by docs.rs, but docs.rs now unconditionally sets the
`--extern-html-root-url` parameter of rustdoc which overrides it, making
it no longer needed and superfluous.
We currently don't have any checks that this crate builds on a `no_std`
target.
While `curve25519-dalek` itself doesn't link `std`, it uses dependencies
which could potentially link `std`, so it's important to have a job to
check that the crate builds on a `no_std` target to ensure feature
activation doesn't accidentally flip on the `std` feature of one of
those dependencies unintentionally.
This adds a job which checks the crate builds on a `thumbv7em-none-eabi`
target which has no `std` implementation.
Previously `alloc` implicitly activated `zeroize` via `zeroize/alloc`.
This commit switches to weak feature activation as added in Rust 1.60,
only activating `zeroize/alloc` if the `zeroize` dependency is
explicitly activated (which it is by default).
* Make `zeroize` an optional dependency
The `zeroize` crate provides a defense against memory read oracles which
typically arise from memory unsafety.
Pure Rust programs may not benefit from `zeroize`, and in certain cases
the unsafe code used by `zeroize` may be more concerning.
This commit makes `zeroize` into an optional feature so users may elect
to disable it if they so desire.
* Added zeroize feature flag to README
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
For the field element types `FieldElement` and `Scalar`, use inherent
constants instead of (non-const) functions to return these constant
values.
It's likely the original functions predate support for inherent
constants, but now that they're available, they're a better fit for
these sort of constant values.
This is a convenience/marker trait for types which impl `CryptoRng` +
`RngCore` which makes the type signatures a little more readable.
It was introduced in `rand_core` v0.6.4 (now pinned as the minimum
version)
build.rs was using cfg(target) but it has to evaluate this from env TARGET
as build.rs cfg(target) in build context is the builder host and not the target.
This change fixes curve25519_dalek_bits lottery to determine the correct
automatic curve25119_dalek_bits with the help of platforms crate.
As discussed in #456 this also prepares for well known defaults for wasm and
arm serial backend via cfg(curve25519_dalek_bits = "64")
If the wasm32 or armv7 are going to be u64 serial by default these will be
followed up on later.
Crate features are intended to be additive, whereas only 1-of-N possible
backends can be selected.
Features can also be activated by transitive dependencies, which leads
to a problem of different dependences selecting conflicting backends.
Using `--cfg` instead moves all backend selection control to the
toplevel executable.
This commit switches to the following RUSTFLAGS to enable backends:
- `--cfg curve25519_dalek_backend="fiat"`: uses `fiat-crypto`
- `--cfg curve25519_dalek_backend="simd"`: uses nightly-only SIMD
