* 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
* 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.
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)
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
Previously `cargo test --no-default-features` would succeed but with
warnings. This commit fixes all of those warnings and tests
`--no-default-features` in CI to ensure that in perpetuity.
As proposed in #442 this makes `digest` an
optional feature that is not covered by the
SemVer public API stability guarantees.
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
As proposed in #442 this makes `rand_core` an
optional feature that is not covered by the
SemVer public API stability guarantees.
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
As suggested in #453 it is sometimes feasible to
select the backend bits via an override.
This change provides `cfg(curve25519_dalek_bits)`
to override the bits used in serial or fiat target backend.
* Deprecated `EdwardsPoint::hash_from_bytes` and renamed to
`EdwardsPoint::nonspec_map_to_curve`
* Added KAT test vectors for `RistrettoPoint::from_uniform_bytes`
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.
As proposed in #426 this commit changes to include README.md into
the crate documentation instead of maintaining a carbon copy in
the code.
This helps to keep the documentation in a single place without
duplicating the documentation in multiple places leading to less
errors and out of date documentation.
