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.
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.
Renames fiat backend directory to fiat_u64 and does the additional plumbing required to make fiat_{u32, u64}_backend equal alternatives.
Adds a few comments.
const_fn is stable since Rust 1.31
(https://github.com/rust-lang/rust/pull/54835) and enables calling
`Scalar::from_bits(..)` from other const fn contexts, potentially
saving some overhead here and there.
Especially useful in contexts where constants are being built from a bit
pattern.
This implements a macro for implementing the BasepointTable trait, and
uses the macro to create basepoint table types. The default table
still uses radix-16 representation and is ~30KB in size. The new
table types, and their memory usage and additions required per
basepoint multiplication are:
* `EdwardsBasepointTableRadix64`: ~120KB, 43 additions
* `EdwardsBasepointTableRadix128`: ~240KB, 37 additions
* `EdwardsBasepointTableRadix256`: ~480KB, 32 additions
The functionality we were using is now contained in the `rand_core` crate, which
we already depend upon. As far as testing code goes, only benchmarks still
depend upon `rand`, as they use `thread_rng`.
`zeroize` is WASM-friendly as it has no dependencies on C compilers.
Instead uses Rust's own volatile write semantics and compiler fences to
ensure zeroization is not elided by the compiler.
This is a breaking change to the serialization format. It fixes it so that the
Serde encoding can match the conventional encoding of each type of object, and
so that Serde can be used with no overhead -- when using serde-bincode, the
Serde encoding now matches the manual encoding.
This ensures that the serde Serialize and Deserialize implementations use
fixed-length Serde tuples, rather than variable-length byte arrays. This flaw
in data modeling was pointed out by Trevor Perrin.
Closes#238.
This issue was discovered independently by both Jack "str4d" Grigg
(issue #238), who noted that reduction was not performed on addition, and
Laurent Grémy & Nicolas Surbayrole of Quarkslab, who noted that it was possible
to cause an overflow and compute incorrect results.
Found by @3for; this only affected width-7 NAF computations, which were never
used in the source tree (only width 5, optimal for dynamic cases, and 8, better
for static cases).
Closes#272
When using Scalar::from_bits to manually create unreduced Scalars (e.g.,
X/Ed25519 keys with specified bit patterns), it's possible to construct Scalar
values that range up to 2^255-1. These shouldn't ever end up in a vartime
multiscalar mul call anyways, because it doesn't handle secret data, but it is
technically allowed by the type system and should be handled. When w=8, these
can generate terminal carries that can't be folded into the last digit, but
this can be handled by folding them into an extra digit instead.
