* Deprecated `EdwardsPoint::hash_from_bytes` and renamed to
`EdwardsPoint::nonspec_map_to_curve`
* Added KAT test vectors for `RistrettoPoint::from_uniform_bytes`
- Consolidate `test` jobs: this allows reusing intermediate artifacts
between tests which should improve build times, and also make it
easier to test additional features in the future
- Switch to `dtolnay/rust-toolchain` for setting up toolchain
- Bump checkout to `actions/checkout@3`
- Switch to `run` directives for invoking Cargo: it's more
straightforward to just call Cargo than use a DSL from an unmaintained
action, and eliminates the 3rd party dependency
Also bumps these corresponding dependencies which are needed for everything to compile with this update:
* `merlin` v3.0
* `rand` v0.8
* `rand_core` v0.6
* `sha2` v0.10
The `RUSTFLAGS` were getting applied to build scripts, which caused them
to crash with SIGILL.
According to this issue, RUSTFLAGS won't be applied to build scripts
when cross-compiling by passing the `--target` attribute:
https://github.com/rust-lang/cargo/issues/4423
This attempts to work around the problem by explicitly passing:
--target x86_64-unknown-linux-gnu
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.
Did a full formatting pass on the crate. Read the comments in the referenced for
steps to verify that the PR made no semantic changes to the code. Huge credit
goes to @robjtede for this work.
This fix eliminates a scenario where a user misuses the `ExpandedSecretKey` API
in a way that leaks the user's secret key. In short, if a user sends
`ExpandedSecretKey::sign(sk, msg, pk1)` followed by
`ExpandedSecretKey::sign(sk, msg, pk2)`, where `pk1 != pk2`, a passive
adversary [can easily][0] derive `sk`. To mitigate this, we remove the API
entirely.
[0]: https://github.com/MystenLabs/ed25519-unsafe-libs
