This PR is a follow-up of #98, which aims to demonstrate the issue brought by small-order public keys. It shows an example of crafting a (public_key, signature) that verifies against two distinct messages using `verify`, but fails using `verify_strict`.
This has consequences on the possibility to repudiate a signed contract of blockchain transactions.
For more details, see:
https://eprint.iacr.org/2020/1244
Joint work with @kchalkias @valerini
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.
* 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`.
