RFC8032 specifies that the context cannot be greater than 255 octets,
but in the previous implementation in ed25519-dalek, this error would
only be caught by a debug_assert. This changes the sign_prehashed()
function to return a Result so that the error can be handled at
runtime and the library no longer allows misuse by creating signatures
that other libraries cannot handle.
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.
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.
This caches the public key internally so that we effectively get a free
speedup on key reuse in regular signature verification, similar to that in
batch verification. (However, this also "speeds up"¹ batch verifications.)
¹ Less of a speed up than moving the computation elsewhere, but the speed up
on reuse still also applies to key reuse for batch verification.
Unfortunately the serialised size is likely never going to be the same
as the type's size in memory, as most serialisation formats define
additional headers for parsing safety reasons, such as buffer lengths
and type information.
generic_array v0.12 no longer serializes GenericArray as a Vec,
which reduces the serialized size of PublicKey, Signature, and
SecretKey by 8 bytes. Now that generic_array has been upgraded,
these tests simply ensure the serialization size doesn't change
in the future.
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
