rust-random/rand#1697 which updates `rand_core` to v0.10.0-rc-3 for the
`rand` crate has been merged.
This removes `patch.crates-io` for `getrandom` and pins to the merged
commit revision for `rand`, as well as bumping the `getrandom`
dependency of `x25519-dalek` to v0.4.0-rc.0.
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`.
* Clarify features in x25519 README
* Remove alloc feature from x25519 bc it was doing nothing
* Add pubkey constructor benchmark
* Correct code size claim on README
* Update changelog
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.
Enforced via the newly added `clippy::mod_module_files` lint.
Previously a mixture of 2015 (`mod.rs`) module files along with
the 2018 `foo.rs` and `foo/` approach.
All of the toplevel modules (`edwards`, `field`, `montgomery`, and
`scalar`) were using the 2018 convention, except for `backend`,
`ristretto`, and the recently added `lizard` were using the 2015
convention.
This renames the files so everything follows the 2018 convention, and
applies the afforementioned clippy lint which will error if anyone tries
to add new files using the 2015 convention.
* Vendor lizard hash to curve from Signal
* Add invalid Lizard encoding test
* Added lizard details to readme and changelog
* Upgrade ristretto.sage to Python3
* Add lizard test vector generation to ristretto.sage
* Added map_to_curve and its inverse
* Use CtOption instead of bitmasks; other cleanup
* Add README to lizard folder
* Split map_to_curve into map_to_curve and map_to_curve_restricted; make its inverse return 16 elements
* Consolidate Ristretto Elligator functions into its own file
* Rename hash_to_curve as encode_to_curve
* Implement the inline description of the standard.
* Generalise map_to_field to return an arbitrary number of field elements.
* Implement hash_to_curve as defined in the standard.
* Put elligator behind the "digest" feature.
* Add warning on non-uniformity of `encode_to_curve`.
* Remove the need of Vec for hash_to_field.
* Apply suggestions from code review
* Refactor expand_message_xmd out of hash_to_field
* Add hash-to-curve to benches
* Constraint COUNT to 1 or 2; add note on secure hash function usage
* Correct hash function usage in encode- and hash-to-curve
---------
Co-authored-by: Armando Faz <armfazh@users.noreply.github.com>
Co-authored-by: Michael Rosenberg <mrosenberg@cloudflare.com>
* [WIP] Scalar::div_by_2
* debug_assert that carry is 0
* revise tests
* Test multiply by half scalar, double and compress (#804)
* Test `div_by_2` with `proptest` (#806)
---------
Co-authored-by: daxpedda <daxpedda@gmail.com>
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.
The types involved are all simple 1-tuple newtypes where zeroization
only involves calling `zeroize` on the inner type, making all of the
involved impls relatively trivial.
Avoiding custom derive arguably improves auditability as you don't need
to expand a proc macro to see the resulting code. It decreases the
number of required dependencies in order for the `zeroize` feature to
work, where some of those dependencies are incredibly heavy
(particularly `syn`).
* Implementation of `hash_to_field` as defined in the standard
* Implementation of `hash_to_curve` as defined in the standard, by changing the mechanism over which we chose the sign.
* For the point above, had to change the `elligator_encode` to return whether `eps` is a square or not (required for `hash_to_curve`).
* Included test vectors of the draft.
* Included `FieldElement::from_bytes_wide(bytes: &u8; 64])` to reduce integers encoded in 64 bytes.
`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`.
