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
We use the [serde_bytes](https://github.com/serde-rs/bytes) crate for
serialization implementations, which simplifies codes and fixes issues
for serde_json.
The `signature` crate provides `Signer` and `Verifier` traits generic
over signature types:
https://github.com/RustCrypto/traits/tree/master/signature
There's presently an open call to stabilize the parts of its API needed
by Ed25519 signatures and release a 1.0 version:
https://github.com/RustCrypto/traits/issues/78
The `ed25519` crate, based on the `signature` crate, provides an
`ed25519::Signature` type which can be shared across multiple Ed25519
crates (e.g. it is also used by the `yubihsm` crate):
https://github.com/RustCrypto/signatures/tree/master/ed25519
This commit integrates the `ed25519::Signature` type, and changes the
existing `sign` and `verify` methods (where applicable) to use the
`Signer` and `Verifier` traits from the `signature` crate. Additionally,
it replaces `SignatureError` with the `signature` crate's error type.
This has the drawback of requiring the `Signer` and/or `Verifier` traits
are in scope in order to create and/or verify signatures, but with the
benefit of supporting interoperability with other Ed25519 crates which
also make use of these traits.
It doesn't appear to me that ed25519-dalek crate needs any of the std-related
features of serde. But it turns them on anyways because it doesn't put
`default-features = false`.
This breaks no_std builds. Otherwise I think we could use 1.0.0-pre3 in mobilecoin.
I'm going to test this revision in our build and see if I'm right. I don't think
this is a breaking change from dalek's point of view.
Previously, we were checking that the highest 3 bits were unset, which still
leaves 2^253 - 2^252 + 27742317777372353535851937790883648493 potential scalars
for the `s` component of a signature which are not strictly mod \ell.
This change fixes that.
Note: This change makes ed25519-dalek incompatible with ed25519-donna in that
some signatures produced by donna will be verifiable by donna but NOT VERIFIABLE
by dalek. On the other hand, libsodium exports a -DED25519_COMPAT feature,
which when enabled, means it is compatible with dalek with the
`legacy_compatibility` feature disabled. Otherwise, libsodium's behaviour is
identical to the behaviour enabled by default in this patch.
* ADD new "batch" feature for feature-gating ed25519 batch verification; off by
default. The "batch" feature is the only thing which depends on all of the
`rand` crate, since it requires the functionality of `rand::thread_rng()`.
Without batch verification, the rest of ed25519-dalek only depends on
`rand_os` and `rand_core`.
This implements https://github.com/dalek-cryptography/ed25519-dalek/issues/64
You can still choose the "prehash" algorithm, as long as it has 64 bytes of
output. Otherwise, everything is hardcoded to use sha2::Sha512. To use a
different implementation you'll need a [patch.crates-io] section in cargo
config.
