* Vendor import unsafe_target_features as curve25519-dalek-derive
Co-authored-by: Jan Bujak <jan@parity.io>
* Remove feature gates from avx2/ifma
* Add buildtime compile diagnostics about backend selection
* Add build script tests
* Documentation changes
* Disable simd related features unless simd was determined via build
* Add note and test about the override warning when unsuccesful
* Reduce complexity in build gating via compile_error
---------
Co-authored-by: Jan Bujak <jan@parity.io>
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
* 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
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>
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>
* Restructure README and CHANGELOG
* Explain semver policy
* Specify feature flags and backends more explicitly
* Remove nightly from the CI bc that didn't belong there
* Add @pinkforest to thankyou list
Co-authored-by: pinkforest <36498018+pinkforest@users.noreply.github.com>
As proposed in #414, this commit changes the backend selection approach,
introspecting `target_pointer_width` to select `u32_backend` vs
`u64_backend` (or `fiat_u32_backend`/`fiat_u64_backend` if the
`fiat_backend` feature is enabled).
This helps eliminate the use of non-additive features, and also the
rather confusing errors that happen if multiple backends are selected
(i.e. thousands of lines of rustc errors).
The selection logic checks if `target_pointer_width = "64"` and uses the
64-bit backend, or falls back to the 32-bit backend otherwise. This
means the crate will always have a valid backend regardless of the
pointer width, although there may be odd edge cases for exotic platforms
which would optimally use the 64-bit backend but have a non-"64" target
pointer width for whatever reason. We can handle those cases as they
come up.
This is too late for the 0.19.0 release (I missed it because I grepped for
"0.18.", and the version in the README doesn't specify a minor version), but it
will now be in line with the other version strings.
When we put out the 1.0.0-pre.0 release we can change both together (our docs
already say we've released it, because we inserted an extra version, oops).
