This enables activating the `alloc` and `std` features without
unnecessarily pulling in optional dependencies like `rand` and `serde`.
It also fixes tests for `--no-default-features` (w\ `--lib` only)
- Add Clippy to CI
- Rename InternalError variants without redundant Error suffix
- Rename to_bytes to as_bytes on well known naming
- Fix Redundant refs
- Fix redundant lifetimes
- Fix late declarations
Change from_bytes methods to take `&[u8; N]` argument (with `N`
appropriate for given type) rather than `&[u8]`. This harmonises
the convention with SigningKey and ed25519::Signature; helps type
inference; and allows users to assert bytes size to be asserted at
compile time.
Creating from a slice is still possible via `TryFrom<&[u8]>` trait.
This is an API breaking change. The simplest way to update existing
code is to replace Foo::from_bytes with Foo::try_from. This should
cover majority of uses.
* Rename `signing` and `verifying` modules
Renames the following modules:
- `keypair` => `signing`
- `public` => `verifying`
Renaming these in an individual commit preserves the commit history.
This is in anticipation of renaming the following per #225:
- `Keypair` => `SigningKey`
- `PublicKey` => `VerifyingKey`
* Rename `Keypair` => `SigningKey`; `PublicKey` => `VerifyingKey`
As proposed in #225, renames key types after their roles:
- `SigningKey` produces signatures
- `VerifyingKey` verifies signatures
The `SecretKey` type is changed to a type alias for `[u8; 32]`, which
matches the RFC8032 definition:
https://www.rfc-editor.org/rfc/rfc8032#section-5.1.5
> The private key is 32 octets (256 bits, corresponding to b) of
> cryptographically secure random data.
Adds optional integration with `ed25519::pkcs8` with support for
decoding/encoding `Keypair` from/to PKCS#8-encoded documents as well as
`PublicKey` from/to SPKI-encoded documents.
Includes test vectors generated for the `ed25519` crate from:
https://github.com/RustCrypto/signatures/tree/master/ed25519/tests/examples
curve25519-dalek:
- Enables `digest` and `rand_core` features
- Removes transitive `nightly`, `simd_backend`, and `std` features
ed25519:
- `AsRef` impl for `Signature` has been removed; uses `to_bytes`
- Uses `try_from` for `InternalSignature` conversion
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
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
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`.
