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.
The API for this isn't the greatest and I apologise for that. Suggestions for
improvement welcome. One thing which @hdevalence and I considered was to
change the function signature to:
pub fn verify_batch<D, C, M, S, K>(messages: M,
signatures: S,
public_keys: K,
csprng: &mut C) -> Result<(), SignatureError>
where D: Digest<OutputSize = U64> + Default,
C: Rng + CryptoRng,
M: IntoIterator<Item = &[u8]>,
S: IntoIterator,
S::Item: Borrow<Signature>,
K: IntoIterator,
K::Item: Borrow<Signature>,
The other improvement which could be made is to implement 128-bit scalars for
the randomnesses.
* CLOSES#27
This also simplifies the verification logic. Because the verification check
happens in variable time, we don't need to do a constant-time eq check at the
end, so we can drop the `subtle` dependency entirely.
The `DecodingError` type becomes `SignatureError` and is also used to
signal failing verifications.
