The package rand has been updated to v0.8.X. As this crate used rand v0.7.X it is not compatible with the current version (1.0.1) of this crate.

And will show error like this:

error[E0277]: the trait bound `OsRng: rand_core::CryptoRng` is not satisfied
   --> lib.rs:20:46
    |
315 |     let keypair: Keypair = Keypair::generate(&mut csprng);
    |                                              ^^^^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `OsRng`
    | 
   ::: ed25519-dalek-1.0.1/src/keypair.rs:129:12
    |
129 |         R: CryptoRng + RngCore,
    |            --------- required by this bound in `Keypair::generate`

error[E0277]: the trait bound `OsRng: rand_core::RngCore` is not satisfied
   --> lib.rs:20:46
    |
315 |     let keypair: Keypair = Keypair::generate(&mut csprng);
    |                                              ^^^^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `OsRng`
    | 
   ::: ed25519-dalek-1.0.1/src/keypair.rs:129:24
    |
129 |         R: CryptoRng + RngCore,
    |                        ------- required by this bound in `Keypair::generate`

On the code that looks like this (similar to example code in documentation).

use rand::rngs::OsRng;

let mut csprng = OsRng {};
let keypair: Keypair = Keypair::generate(&mut csprng);

So for the next version of this crate the rand version should be updated. Current workaround is to downgrade to rand version 0.7.X.

The least disruptive API changes might be turn ExpandedSecretKey::sign_*() to pub(crate), leaving only the correct KeyPair.sign_*() API for signing to public invocation, which is always correct and not vulnerable to "Signing Function Oracle" attack.

NOTE: PR open with these proposed changes here #124

Problem

Crates which use Ed25519 as part of a high-level protocol implementation or abstract signature functionality who want to enable the consumers of their crates to be able to use their choice of Rust Ed25519 libraries wind up writing their own abstractions to do so on a crate-by-crate basis.

Here's an example from the Noise Protocol implementation snow, which does not (yet) use Ed25519 signatures, but I hope still illustrates the point:

Instead of every crate which wants to do this having to wrangle a silly zoo of optional crypto crates dependencies, a better approach would be to define a common set of traits for how to produce (Ed25519) signatures, and encourage algorithm "provider" crates to impl those traits. This makes it easy to, say, use ed25519-dalek as a software signing crate while also supporting the yubihsm crate for hardware-backed Ed25519 signatures.

signature crate

I've been working with @newpavlov via the RustCrypto GH org to create a crate which provides abstract digital signature functionality, which I plan on using to rewrite the internals of Signatory, an existing multi-provider digital signature library.

Where Signatory provides a set of compatible "provider" crates, e.g. signatory-dalek, what I would really love to do as part of a minimalist rewrite is also get crypto library authors to adopt the traits directly into their libraries instead of using "wrapper" crates which impl the relevant traits. And congratulations, you're the first project I'm pinging.

I've just opened a PR to the signature crate which implements the initial set of signing traits:

https://github.com/RustCrypto/signatures/pull/7

(Sidebar: If you see anything you don't like there, please let us know! This is the first major non-boilerplate PR to the crate, so now is a great time to fix anything you don't like about it)

Namely it has traits like these:

pub trait Sign<S: Signature>: Send + Sync {
    fn sign(&self, msg: &[u8]) -> Result<S, Error>;
}

pub trait Verify<S: Signature>: Send + Sync {
    fn verify(&self, msg: &[u8], signature: &S) -> Result<(), Error>;
}

These traits provide equivalent methods to the existing Keypair::sign and PublicKey::verify methods (the only difference being the Sign trait returns a Result for its sign method, in which case it might be worth considering separating sign from try_sign so people who don't care about things like HSM errors don't always need to call unwrap).

Having people import an additional trait is, I will admit, mildly annoying, but I imagine most people are copying/pasting the relevant code, so adding an additional import is not that annoying. You can re-export the relevant traits similar to what you're already doing for Digest.

ed25519 crate

~~For true interop, crates need to agree on at least an ed25519::Signature type. That said, the ed25519 crate is presently vaporware and these types don't yet exist.~~ Update: it's real, and used in production in a few crates, e.g. yubihsm.

One option, if you are so inclined as authors of what is pretty much the definitive Rust Ed25519 crate, would be to upstream the existing Signature type into the ed25519 crate.

All that said, I'm happy to both make changes to the signature crate as well as put in a PR to ed25519-dalek to switch to using these traits once we publish the initial signature crate. Let me know if you're interested!

In serde, the fixed length byte array (i.e. [u8; LENGTH]) and normal byte array (i.e., &[u8]) are two different data types. In the previous implementation, these two data types are mixed together. As such, the deserialization operation will fail for certain encoding like json.

This PR fixes this issue by using the fixed length byte array as the serde internal data types for all data structures. This also comes with the benefit to reduce the size of the encoded data.

We also add more tests to prevent future breakage.

Noted that this PR introduced breaking changes. However, the previous serde implementation was already partially broken.

I expect for most users this is fine, and if some user would like to use a different Rng they can use the from_bytes call.

Since rand has a history of causing breakage in ed25519-dalek I think this change could be justified as a bug fix.

Also updates the dependencies to new versions where appropriate.

Closes #160 Closes #159 Closes #162

Reproduce:

build the following minimal crate: https://github.com/scs/test-no-std/tree/ed25519-dalek

cargo build --no-default-features results in

error: duplicate lang item in crate `std`: `f32_runtime`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `f64_runtime`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `panic_impl`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `begin_panic`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `oom`.
  |
  = note: first defined in crate `sgx_tstd`.

error: aborting due to 5 previous errors

error: Could not compile `test_no_std`.

When interacting with other Ed25519 libraries one might need to be able to bring in a Public Key which is in x + y form ([u8,64]). One might also want to export the x + y form.

Neither of these use cases is currently supported by ed25519-dalek, which can be a deal breaker for some users. Is there something I'm missing that would allow the export of the public key in expanded form? Is there interest in adding this kind of support if it's not already possible?

Steps to reproduce

Cloning into 'rustup3'...
remote: Enumerating objects: 17372, done.        
remote: Total 17372 (delta 0), reused 0 (delta 0), pack-reused 17372        
Receiving objects: 100% (17372/17372), 6.09 MiB | 1.12 MiB/s, done.
Resolving deltas: 100% (11820/11820), done.
rustcargo@zealot:~/Rustup/Itself$ cd rustup3/
rustcargo@zealot:~/Rustup/Itself/rustup3$ cargo build
...
   Compiling ed25519-dalek v1.0.0-pre.3
...
    Finished dev [unoptimized + debuginfo] target(s) in 1m 19s

Observe that the build works, and that this is with 1.0.0-pre3. Now switch to 1.0.0-pre4:

rustcargo@zealot:~/Rustup/Itself/rustup3$ cargo update -p ed25519-dalek --precise 1.0.0-pre.4
    Updating crates.io index
      Adding ed25519 v1.0.1
    Updating ed25519-dalek v1.0.0-pre.3 -> v1.0.0-pre.4
      Adding signature v1.1.0
rustcargo@zealot:~/Rustup/Itself/rustup3$ cargo build                                        
   Compiling signature v1.1.0
   Compiling rustup v1.22.1 (/volatile/rustcargo/Rustup/Itself/rustup3)
   Compiling ed25519 v1.0.1
   Compiling ed25519-dalek v1.0.0-pre.4
   Compiling pgp v0.5.2
error[E0599]: no function or associated item named `from_bytes` found for struct `ed25519_dalek::Signature` in the current scope
  --> /home/rustcargo/.cargo/registry/src/github.com-1ecc6299db9ec823/pgp-0.5.2/src/crypto/eddsa.rs:58:49
   |
58 |             let sig = ed25519_dalek::Signature::from_bytes(&sig_bytes)?;
   |                                                 ^^^^^^^^^^
   |                                                 |
   |                                                 function or associated item not found in `ed25519_dalek::Signature`
   |                                                 help: there is an associated function with a similar name: `to_bytes`
   |
   = help: items from traits can only be used if the trait is in scope
   = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
           `use ed25519_dalek::ed25519::signature::Signature;`

error[E0599]: no method named `verify` found for struct `ed25519_dalek::PublicKey` in the current scope
  --> /home/rustcargo/.cargo/registry/src/github.com-1ecc6299db9ec823/pgp-0.5.2/src/crypto/eddsa.rs:60:16
   |
60 |             pk.verify(hashed, &sig)?;
   |                ^^^^^^ method not found in `ed25519_dalek::PublicKey`
   |
   = help: items from traits can only be used if the trait is in scope
   = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
           `use ed25519_dalek::Verifier;`

error[E0599]: no method named `sign` found for struct `ed25519_dalek::Keypair` in the current scope
  --> /home/rustcargo/.cargo/registry/src/github.com-1ecc6299db9ec823/pgp-0.5.2/src/crypto/eddsa.rs:83:24
   |
83 |     let signature = kp.sign(digest);
   |                        ^^^^ method not found in `ed25519_dalek::Keypair`
   |
   = help: items from traits can only be used if the trait is in scope
   = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
           `use ed25519_dalek::Signer;`

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `pgp`.

To learn more, run the command again with --verbose.
rustcargo@zealot:~/Rustup/Itself/rustup3$ 

Sorry for not minimising this further. I tried producing a repro based only on rpgp, but ran into probably-unrelated trouble.

cc @kinnison

Change from_bytes methods of all the types to take &[u8; N] argument (with N appropriate for given type) rather than &[u8]. This does a few things:

• it makes SecretKey::from_bytes infallible which will simplify call sites (if the call site already has properly-sized array),
• harmonises the convention with ed25519::Signature::from_bytes method and
• encodes the size of the bytes representation in type system which means that users can assert it at compile time.

To still allow creating the objects from a slice whose size is checked at run time, introduce TryFrom<&[u8]> implementations for affected public types.

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.

~~NOTE: depends on #222 and #223 which need to be merged first.~~

Adds optional integration with ed25519::pkcs8 with support for decoding/encoding Keypair from/to PKCS#8-encoded documents.

~~TODO: support for decoding/encoding PublicKey from/to SPKI documents.~~ Added, good to go!

In the @RustCrypto project we have adopted a convention of naming signature keys SigningKey and VerifyingKey which describes keys by their roles in a signature system.

The basic pitch is that such names are clearer and more intuitive to users who don't necessarily have a background in cryptography.

Would it make sense to adopt similar names in this crate?

This transitively updates signature to v2.0.0-rc.1, which contains RNG API changes which don't impact ed25519-dalek, as it doesn't use or enable the RNG API.

Updates to the latest upstream changes in curve25519-dalek, including using the new EdwardsPoint::mul_base API.

To keep the build deterministic, this also checks in Cargo.lock, which pins curve25519-dalek to a particular git commit SHA which can be updated using cargo update -p curve25519-dalek.

We can potentially remove Cargo.lock again after a crate release.

Previously we had batch and batch_deterministic features, which would do a different thing under the hood depending on what you picked. This PR removes all nondeterminism from batch verification, and simply uses Merlin for everything. This is for a few reasons:

1. Having 2 mutually exclusive flags is a pain point in the API. And splitting them into two functions is similarly annoying.
2. I couldn't find any arguments for the use of nondeterminism in batch verif. There's the old docs (which this PR deletes), which links to Merlin's reasoning and Trevor Perrin's reasoning, but they are talking about signing, not verifying. It is perfectly sound to use Merlin to apply the Fiat-Shamir transform to this protocol and use its randomness for verification.

I only have two arguments against this PR:

1. If there is any part of the transcript that we did not properly hash into the context, it could allow an attacker to brute force a transcript that causes verify_batch to succeed on a bad signature. I think this is unlikely, given the transcript hash is done in 3 lines and consumes literally every input to the function in the process. Unfortunately, this claim requires some deep code checking. For example, the signatures that are hashed are actually the result of InternalSignature::into. Is this accidentally two-to-one? The answer is no but it requires you to check how scalars and points are deserialized. I don't think there's a problem here, but I can make the code more obviously correct by hashing in the un-converted input values. Update: I did this
2. You could brute-force verif so that it succeeds on specific ill-formed pubkey-signature pairs (i.e., the low-order R and A values that pass our validation criteria). However, even a nondeterministic batch function will succeed on these batches with 1/8 probability (technically, (1/8)^n for n such items in a batch). How much do we care if the alternative has such a high likelihood of false positive as well? I think this if anything, this is a good argument to use the batched equation, which multiplies by the cofactor and accepts all of these 100% of the time.

~~NOTE: depends on https://github.com/dalek-cryptography/curve25519-dalek/pull/489 which needs to be merged first~~ Merged!

NOTE: now depends on #260 which needs to be merged first

Disabling the feature reduces overall code size at the cost of performance, which is useful for e.g. embedded users.

This feature transitively enables the basepoint-tables feature in curve25519-dalek.

~~TODO: fallback support for using variable-base scalar multiplication by the basepoint when the basepoint-tables feature is disabled.~~ Added in 8f56c5c

Hello. Please forgive my ignorance, but the radix documentation states that radices greater than 256 are prohibited, and radix 32 is unsupported. It says higher radices are not supported to save cache space, but my understanding is that generalizing the function would not incur additional cache costs for the existing racides. Would it be advantageous, then, to write a generic radix function, like to_radix_2W<const W: usize> -> [i8; (256 + W - 1)/W + 1], or, if generic const expressions are permissible, to_radix_2W<const W: usize> -> [i8; to_radix_2w_size_hint(W)] Theres obviously the possibility that this introduces some side channel attack, but, if this is the case, could this be documented? Even so, I think it would be safer to have an implementation for higher radices here, where it can be audited with everything else, than have every library user write their own, each with their own attack surfaces. I want to be very careful about timing and cache vulnerabilities here particularly, but I also want larger radices, so I'm really not sure what to do here. Any advice would be appreciated. Thank you!