This fix eliminates a scenario where a user misuses the `ExpandedSecretKey` API
in a way that leaks the user's secret key. In short, if a user sends
`ExpandedSecretKey::sign(sk, msg, pk1)` followed by
`ExpandedSecretKey::sign(sk, msg, pk2)`, where `pk1 != pk2`, a passive
adversary [can easily][0] derive `sk`. To mitigate this, we remove the API
entirely.
[0]: https://github.com/MystenLabs/ed25519-unsafe-libs
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.
