- 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
We use the [serde_bytes](https://github.com/serde-rs/bytes) crate for
serialization implementations, which simplifies codes and fixes issues
for serde_json.
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.
