Most of the changes in this PR are actually from the associated `rand`
crate updates which are happening in rust-random/rand#1697, notably
`OsRng` has been renamed to `SysRng` (and is now provided by the
`getrandom` crate).
We do use some `rand_core` APIs in a few places though, like the STROBE
implementation, where this migrates from `rand_core::le` to
`rand_core::utils`.
Prior to a final stable release of the @RustCrypto dependencies used by
the dalek crates, we are going to target `rand_core` v0.10.
This updates the `rand` and `rand_core` dependencies as well as the
aforementioned @RustCrypto dependencies to be compatible with
`rand_core` v0.10, which incurred a few API changes:
- `rand_core` no longer includes `OsRng`, so this replaces the `os_rng`
features with `getrandom` features (same thing we did for @RustCrypto)
which uses the `getrandom` crate directly
- For `dev-dependencies` it just migrates straight to `rand`, replacing
`rand_chacha` with the `chacha` feature of `rand` (which pulls in
`chacha20`), and sourcing `OsRng` from `rand`, its new home (for now)
This PR also switches to using the `rustcrypto-ff`/`rustcrypto-group` crates
(hopefully temporary) which are forks of `ff` and `group` which have crate
releases that have been updated to use `rand_core` v0.10.0 prereleases.
When pulling crates via git (to grab non-released yet fixes or
otherwise), the `path = "../"` in each crate crates duplicates unless
you pull the whole tree in your local `[patch.crates-io]`.
This creates issues in downstream packaging (nix, ...) where a crate
version can only appear once.
Those are somewhat difficult to diagnose.
Using a `[patch.crates-io]` in the workspace serves the same purpose but
does not create the duplication in consumers' tree.
* Update changelogs and readmes
* Fix missing/wrong features in readmes
* ed: Remove std entirely
* ed: Fix deprecated warnings in bench
* Document removing std from ed
This represents the first breaking change in a new release series,
bumping all crates to the 2024 edition of Rust.
As such, the version numbers of all crates have been incremented to
represent a new prerelease series:
- `curve25519-dalek`: v5.0.0-pre
- `ed25519-dalek`: v3.0.0-pre
- `x25519-dalek`: v3.0.0-pre
Note that this commit isn't intended to cut associated crate releases of
these on crates.io, but is merely bumping the version numbers to denote
there are pending breaking changes.
This commit also includes rustfmt changes which were made as part of the
2024 edition.
Also includes clippy fixes.
`merlin` is currently a blocker for upgrading to `rand_core` v0.9 by way
of the `transcript.build_rng().finalize()` function (which we only pass
`ZeroRng` to).
There is an open PR to update `rand_core` in `merlin` and I have pinged
the relevant people to take a look, hopefully: zkcrypto/merlin#11
However, in the event we can't get `merlin` updated, this at least
unblocks the `rand_core` upgrade, and is being opened as a contingency
plan for that case.
The PR has been implemented in a way that it should be easy to switch
back to upstream `merlin` in the event they upgrade `rand_core`.
* Replace recompute_R with a separate RCompute
This struct can be use to implement verifiers with incremental updates
* Add raw_sign_byupdate and raw_verify_byupdate
These allow signing/verifying a non-prehashed message
but don't require the whole message to be provided at once.
* Tests for raw_sign_byupdate, raw_verify_byupdate
* Add StreamVerifier
* Make StreamVerifier use RCompute
This allows it to use the same implementation as non-stream signature
verification.
* Guard StreamVerifier behind hazmat feature
* docs: disambiguate unsafety
Co-authored-by: Tony Arcieri <bascule@gmail.com>
* chore: relax F bounds on raw_verify_byupdate
* chore: remove raw_sign_byupdate and raw_verify_byupdate
* chore: address clippy lints within new code
* docs: fixup changelog
* test: invert new chunked test
* chore: revert raw_sign
---------
Co-authored-by: Matt Johnston <matt@ucc.asn.au>
Co-authored-by: Tony Arcieri <bascule@gmail.com>
Removes the previous warning that points are unvalidated: they're
validated using the ZIP-215 rules, which allows unreduced y-coordinates.
Points are ensured valid by performing decompression, which finds a
solution to the curve equation, or returns an error.
Adds references to ZIP-215 and dalek-cryptography/curve25519-dalek#626
which is an issue about potentially adding support for the RFC8032/NIST
validation criteria in the future.
