README changes for 2.0 (#275)

* Added items to changelog for 2.0 release

* Removed unnecessary uses of std in doctests

* Gated `Context` behind `digest`

* Fixed noncompiling doctest when only `digest` is enabled

* README feature flag list mostly done

* Copied changelog to readme

* Redid the malleability section in README

* Added CONTRIBUTING.md

* Bumped version number to 2.0.0-pre.0; small changes to README

* Updated changelog for #277

* Added pem feature description

Co-authored-by: pinkforest(she/her) <36498018+pinkforest@users.noreply.github.com>

CHANGELOG.md

@@ -4,9 +4,33 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## Unreleased
+Entries are listed in reverse chronological order per undeprecated major series.
 
-### Changes
+# 2.x series
-* Bumped MSRV from 1.41 to 1.60.0
+
-* Removed `ExpandedSecretKey` API ((#205)[https://github.com/dalek-cryptography/ed25519-dalek/pull/205])
+##  2.0.0
-* Implemented `Clone` for `SigningKey`
+
+### Breaking changes
+
+* Bump MSRV from 1.41 to 1.60.0
+* Bump Rust edition
+* Bump `signature` dependency to 2.0
+* Make [curve25519-backend selection](https://github.com/dalek-cryptography/curve25519-dalek/#backends) more automatic
+* Make `digest` an optional dependency
+* Make `zeroize` an optional dependency
+* Make `rand_core` an optional dependency
+* Make all batch verification deterministic remove `batch_deterministic` ([#256](https://github.com/dalek-cryptography/ed25519-dalek/pull/256))
+* Remove `ExpandedSecretKey` API ((#205)[https://github.com/dalek-cryptography/ed25519-dalek/pull/205])
+* Rename `Keypair` → `SigningKey` and `PublicKey` → `VerifyingKey`
+
+### Other changes
+
+* Add `Context` type for prehashed signing
+* Add `VerifyingKey::{verify_prehash_strict, is_weak}`
+* Add `pkcs` feature to support PKCS #8 (de)serialization of `SigningKey` and `VerifyingKey`
+* Add `fast` feature to include basepoint tables
+* Add tests for validation criteria
+* Impl `DigestSigner`/`DigestVerifier` for `SigningKey`/`VerifyingKey`, respectively
+* Impl `Hash` for `VerifyingKey`
+* Impl `Clone`, `Drop`, and `ZeroizeOnDrop` for `SigningKey`
+* Remove `rand` dependency

CONTRIBUTING.md

@@ -0,0 +1,19 @@
+# Contributing to ed25519-dalek
+
+If you have questions or comments, please feel free to email the
+authors. 
+
+For feature requests, suggestions, and bug reports, please open an issue on
+[our Github](https://github.com/dalek-cryptography/ed25519-dalek).  (Or, send us
+an email if you're opposed to using Github for whatever reason.)
+
+Patches are welcomed as pull requests on
+[our Github](https://github.com/dalek-cryptography/ed25519-dalek), as well as by
+email (preferably sent to all of the authors listed in `Cargo.toml`).
+
+All issues on ed25519-dalek are mentored, if you want help with a bug just
+ask @tarcieri or @rozbb.
+
+Some issues are easier than others. The `easy` label can be used to find the
+easy issues. If you want to work on an issue, please leave a comment so that we
+can assign it to you!

Cargo.lock

@@ -287,7 +287,7 @@ dependencies = [
 
 [[package]]
 name = "ed25519-dalek"
-version = "1.0.1"
+version = "2.0.0-pre.0"
 dependencies = [
  "bincode",
  "criterion",

Cargo.toml

@@ -1,12 +1,15 @@
 [package]
 name = "ed25519-dalek"
-version = "1.0.1"
+version = "2.0.0-pre.0"
 edition = "2021"
-authors = ["isis lovecruft <isis@patternsinthevoid.net>"]
+authors = [
+    "isis lovecruft <isis@patternsinthevoid.net>",
+    "Tony Arcieri <bascule@gmail.com>",
+    "Michael Rosenberg <michael@mrosenberg.pub>"
+]
 readme = "README.md"
 license = "BSD-3-Clause"
 repository = "https://github.com/dalek-cryptography/ed25519-dalek"
-homepage = "https://dalek.rs"
 documentation = "https://docs.rs/ed25519-dalek"
 keywords = ["cryptography", "ed25519", "curve25519", "signature", "ECC"]
 categories = ["cryptography", "no-std"]

README.md

@@ -1,55 +1,67 @@
-# ed25519-dalek [![](https://img.shields.io/crates/v/ed25519-dalek.svg)](https://crates.io/crates/ed25519-dalek) [![](https://docs.rs/ed25519-dalek/badge.svg)](https://docs.rs/ed25519-dalek) [![](https://travis-ci.org/dalek-cryptography/ed25519-dalek.svg?branch=master)](https://travis-ci.org/dalek-cryptography/ed25519-dalek?branch=master)
+# ed25519-dalek [![](https://img.shields.io/crates/v/ed25519-dalek.svg)](https://crates.io/crates/ed25519-dalek) [![](https://docs.rs/ed25519-dalek/badge.svg)](https://docs.rs/ed25519-dalek) [![Rust](https://github.com/dalek-cryptography/ed25519-dalek/actions/workflows/rust.yml/badge.svg?branch=main)](https://github.com/dalek-cryptography/ed25519-dalek/actions/workflows/rust.yml)
 
 Fast and efficient Rust implementation of ed25519 key generation, signing, and
-verification in Rust.
+verification.
 
 # Use
 
-To use, add the following to your project's `Cargo.toml`:
+## Stable
 
+To import `ed25519-dalek`, add the following to the dependencies section of
+your project's `Cargo.toml`:
 ```toml
-[dependencies.ed25519-dalek]
+ed25519-dalek = "1"
-version = "1"
+```
+
+## Beta
+
+To use the latest prerelease (see changes [below](#breaking-changes-in-200)),
+use the following line in your project's `Cargo.toml`:
+```toml
+ed25519-dalek = "2.0.0-pre.0"
 ```
 
 # Feature Flags
 
-This crate is `#[no_std]` compatible with `default-features = false`
+This crate is `#[no_std]` compatible with `default-features = false`.
 
 | Feature                | Default? | Description |
 | :---                   | :---     | :---        |
-| `alloc`                | ✓        | Enables features that require dynamic heap allocation |
+| `alloc`                | ✓        | When `pkcs8` is enabled, implements `EncodePrivateKey`/`EncodePublicKey` for `SigningKey`/`VerifyingKey`, respectively. |
-| `std`                  | ✓        | std::error::Error types |
+| `std`                  | ✓        | Implements `std::error::Error` for `SignatureError`. Also enables `alloc`. |
-| `zeroize`              | ✓        | Enables `Zeroize` for `SigningKey` |
+| `zeroize`              | ✓        | Implements `Zeroize` and `ZeroizeOnDrop` for `SigningKey` |
-| `asm`                  |          | Assembly implementation of SHA-2 compression functions |
+| `rand_core`            |          | Enables `SigningKey::generate` |
-| `batch`                |          | Batch verification. Requires `alloc` |
+| `batch`                |          | Enables `verify_batch` for verifying many signatures quickly. Also enables `rand_core`. |
-| `digest`               |          | TODO |
+| `digest`               |          | Enables `Context`, `SigningKey::{with_context, sign_prehashed}` and `VerifyingKey::{with_context, verify_prehashed, verify_prehashed_strict}` for Ed25519ph prehashed signatures |
-| `legacy_compatibility` |          | See: A Note on Signature Malleability |
+| `asm`                  |          | Enables assembly optimizations in the SHA-512 compression functions |
-| `pkcs8`                |          | PKCS#8 Support |
+| `pkcs8`                |          | Enables [PKCS#8](https://en.wikipedia.org/wiki/PKCS_8) serialization/deserialization for `SigningKey` and `VerifyingKey` |
-| `pem`                  |          | PEM Support |
+| `pem`                  |          | Enables PEM serialization support for PKCS#8 private keys and SPKI public keys. Also enables `alloc`. |
-| `rand_core`            |          | TODO        |
+| `legacy_compatibility` |          | **Unsafe:** Disables certain signature checks. See [below](#malleability-and-the-legacy_compatibility-feature) |
 
 # Major Changes
 
 See [CHANGELOG.md](CHANGELOG.md) for a list of changes made in past version of this crate.
 
-## 2.0.0 Breaking Changes
+## Breaking Changes in 2.0.0
 
-* Update the MSRV from 1.41 to 1.60
+* Bump MSRV from 1.41 to 1.60.0
-* `batch` is now `batch_deterministic`
+* Bump Rust edition
-* Removed `ExpandedSecretKey` API
+* Bump `signature` dependency to 2.0
-* [curve25519-backend selection] is more automatic
+* Make [curve25519-backend selection](https://github.com/dalek-cryptography/curve25519-dalek/#backends) more automatic
-
+* Make `digest` an optional dependency
-[curve25519-backend selection]: https://github.com/dalek-cryptography/curve25519-dalek/#backends
+* Make `zeroize` an optional dependency
+* Make `rand_core` an optional dependency
+* Make all batch verification deterministic remove `batch_deterministic` ([#256](https://github.com/dalek-cryptography/ed25519-dalek/pull/256))
+* Remove `ExpandedSecretKey` API ((#205)[https://github.com/dalek-cryptography/ed25519-dalek/pull/205])
+* Rename `Keypair` → `SigningKey` and `PublicKey` → `VerifyingKey`
 
 # Documentation
 
 Documentation is available [here](https://docs.rs/ed25519-dalek).
 
-# Policies
+# Compatibility Policies
-
-All on-by-default features of this library are covered by semantic versioning (SemVer)
 
+All on-by-default features of this library are covered by [semantic versioning](https://semver.org/spec/v2.0.0.html) (SemVer).
 SemVer exemptions are outlined below for MSRV and public API.
 
 ## Minimum Supported Rust Version
@@ -59,11 +71,11 @@ SemVer exemptions are outlined below for MSRV and public API.
 | 2.x      | 1.60   |
 | 1.x      | 1.41   |
 
-MSRV changes will be accompanied by a minor version bump.
+From 2.x and on, MSRV changes will be accompanied by a minor version bump.
 
 ## Public API SemVer Exemptions
 
-Breaking changes to SemVer exempted components affecting the public API will be accompanied by some version bump.
+Breaking changes to SemVer-exempted components affecting the public API will be accompanied by some version bump.
 
 Below are the specific policies:
 
@@ -71,9 +83,11 @@ Below are the specific policies:
 | :---     | :---                    | :---   |
 | 2.x      | Dependencies `digest`, `pkcs8` and `rand_core` | Minor SemVer bump |
 
-## Safety
+# Safety
 
-This crate does not require any unsafe and forbids all unsafe in-crate outside tests.
+`ed25519-dalek` is designed to prevent misuse. Signing is constant-time, all signing keys are zeroed when they go out of scope (unless `zeroize` is disabled), detached public keys [cannot](https://github.com/MystenLabs/ed25519-unsafe-libs/blob/main/README.md) be used for signing, and extra functions like [`VerifyingKey::verify_strict`](#weak-key-forgery-and-verify_strict) are made available to avoid known gotchas.
+
+Further, this crate has no—and in fact forbids—unsafe code. You can opt in to using some highly optimized unsafe code that resides in `curve25519-dalek`, though. See [below](#microarchitecture-specific-backends) for more information on backend selection.
 
 # Performance
 
@@ -108,110 +122,65 @@ On an Intel 10700K running at stock comparing between the `curve25519-dalek` bac
 | batch signature verification/256| 4.1868 ms | 2.8864 ms -31.061% | 4.6494 ms +61.081% |
 | keypair generation              | 13.973 µs | 13.108 µs -6.5062% | 15.099 µs +15.407% |
 
-Additionally, if you're using a CSPRNG from the `rand` crate, the `nightly`
-feature will enable `u128`/`i128` features there, resulting in potentially
-faster performance.
-
 ## Batch Performance
 
 If your protocol or application is able to batch signatures for verification,
-the `verify_batch()` function has greatly improved performance.
+the [`verify_batch`][func_verify_batch] function has greatly improved performance.
 
 As you can see, there's an optimal batch size for each machine, so you'll likely
 want to test the benchmarks on your target CPU to discover the best size.
 
 ## (Micro)Architecture Specific Backends
 
-`ed25519-dalek` uses the backends from the `curve25519-dalek` crate.
+A _backend_ refers to an implementation of elliptic curve and scalar arithmetic. Different backends have different use cases. For example, if you demand formally verified code, you want to use the `fiat` backend (as it was generated from [Fiat Crypto][fiat]). If you want the highest performance possible, you probably want the `simd` backend.
 
-By default the serial backend is used and depending on the target
+Backend selection details and instructions can be found in the [curve25519-dalek docs](https://github.com/dalek-cryptography/curve25519-dalek#backends).
-platform either the 32 bit or the 64 bit serial formula is automatically used.
-
-To address variety of  usage scenarios various backends are available that
-include hardware optimisations as well as a formally verified fiat crypto
-backend that does not use any hardware optimisations.
-
-These backends can be overriden with various configuration predicates (cfg)
-
-Please see the [curve25519_dalek backend documentation](https://docs.rs/curve25519-dalek/latest/curve25519_dalek).
 
 # Contributing
 
 See [CONTRIBUTING.md](CONTRIBUTING.md)
 
-# A Note on Signature Malleability
+# Batch Signature Verification
 
-The signatures produced by this library are malleable, as discussed in
+The standard variants of batch signature verification (i.e. many signatures made with potentially many different public keys over potentially many different messages) is available via the `batch` feature. It uses deterministic randomness, i.e., it hashes the inputs (using [`merlin`](https://merlin.cool/), which handles transcript item separation) and uses the result to generate random coefficients. Batch verification requires allocation, so this won't function in heapless settings.
-[the original paper](https://ed25519.cr.yp.to/ed25519-20110926.pdf):
 
-![](https://cdn.jsdelivr.net/gh/dalek-cryptography/ed25519-dalek/docs/assets/ed25519-malleability.png)
+# Validation Criteria
 
-While the scalar component of our `Signature` struct is strictly *not*
+The _validation criteria_ of a signature scheme are the criteria that signatures and public keys must satisfy in order to be accepted. Unfortunately, Ed25519 has some underspecified parts, leading to different validation criteria across implementations. For a very good overview of this, see [Henry's post][validation].
-malleable, because reduction checks are put in place upon `Signature`
-deserialisation from bytes, for all types of signatures in this crate,
-there is still the question of potential malleability due to the group
-element components.
 
-We could eliminate the latter malleability property by multiplying by the curve
+In this section, we mention some specific details about our validation criteria, and how to navigate them.
-cofactor, however, this would cause our implementation to *not* match the
-behaviour of every other implementation in existence.  As of this writing,
-[RFC 8032](https://tools.ietf.org/html/rfc8032), "Edwards-Curve Digital
-Signature Algorithm (EdDSA)," advises that the stronger check should be done.
-While we agree that the stronger check should be done, it is our opinion that
-one shouldn't get to change the definition of "ed25519 verification" a decade
-after the fact, breaking compatibility with every other implementation.
 
-However, if you require this, please see the documentation for the
+## Malleability and the `legacy_compatibility` Feature
-`verify_strict()` function, which does the full checks for the group elements.
-This functionality is available by default.
 
-If for some reason—although we strongly advise you not to—you need to conform
+A signature scheme is considered to produce _malleable signatures_ if a passive attacker with knowledge of a public key _A_, message _m_, and valid signature _σ'_ can produce a distinct _σ'_ such that _σ'_ is a valid signature of _m_ with respect to _A_. A scheme is only malleable if the attacker can do this _without_ knowledge of the private key corresponding to _A_.
-to the original specification of ed25519 signatures as in the excerpt from the
-paper above, you can disable scalar malleability checking via
-`--features='legacy_compatibility'`.  **WE STRONGLY ADVISE AGAINST THIS.**
 
-## The `legacy_compatibility` Feature
+`ed25519-dalek` is not a malleable signature scheme.
 
-By default, this library performs a stricter check for malleability in the
+Some other Ed25519 implementations are malleable, though, such as [libsodium with `ED25519_COMPAT` enabled](https://github.com/jedisct1/libsodium/blob/24211d370a9335373f0715664271dfe203c7c2cd/src/libsodium/crypto_sign/ed25519/ref10/open.c#L30), [ed25519-donna](https://github.com/floodyberry/ed25519-donna/blob/8757bd4cd209cb032853ece0ce413f122eef212c/ed25519.c#L100), [NaCl's ref10 impl](https://github.com/floodyberry/ed25519-donna/blob/8757bd4cd209cb032853ece0ce413f122eef212c/fuzz/ed25519-ref10.c#L4627), and probably a lot more.
-scalar component of a signature, upon signature deserialisation.  This stricter
+If you need to interoperate with such implementations and accept otherwise invalid signatures, you can enable the `legacy_compatibility` flag. **Do not enable `legacy_compatibility`** if you don't have to, because it will make your signatures malleable.
-check, that `s < \ell` where `\ell` is the order of the basepoint, is
-[mandated by RFC8032](https://tools.ietf.org/html/rfc8032#section-5.1.7).
-However, that RFC was standardised a decade after the original paper, which, as
-described above, (usually, falsely) stated that malleability was inconsequential.
 
-Because of this, most ed25519 implementations only perform a limited, hackier
+Note: [CIRCL](https://github.com/cloudflare/circl/blob/fa6e0cca79a443d7be18ed241e779adf9ed2a301/sign/ed25519/ed25519.go#L358) has no scalar range check at all. We do not have a feature flag for interoperating with the larger set of RFC-disallowed signatures that CIRCL accepts.
-check that the most significant three bits of the scalar are unset.  If you need
-compatibility with legacy implementations, including:
 
-* ed25519-donna
+## Weak key Forgery and `verify_strict()`
-* Golang's /x/crypto ed25519
-* libsodium (only when built with `-DED25519_COMPAT`)
-* NaCl's "ref" implementation
-* probably a bunch of others
 
-then enable `ed25519-dalek`'s `legacy_compatibility` feature.  Please note and
+A _signature forgery_ is what it sounds like: it's when an attacker, given a public key _A_, creates a signature _σ_ and message _m_ such that _σ_ is a valid signature of _m_ with respect to _A_. Since this is the core security definition of any signature scheme, Ed25519 signatures cannot be forged.
-be forewarned that doing so allows for signature malleability, meaning that
-there may be two different and "valid" signatures with the same key for the same
-message, which is obviously incredibly dangerous in a number of contexts,
-including—but not limited to—identification protocols and cryptocurrency
-transactions.
 
-## The `verify_strict()` Function
+However, there's a much looser kind of forgery that Ed25519 permits, which we call _weak key forgery_. An attacker can produce a special public key _A_ (which we call a _weak_ public key) and a signature _σ_ such that _σ_ is a valid signature of _any_ message _m_, with respect to _A_, with high probability. This attack is acknowledged in the [Ed25519 paper](https://ed25519.cr.yp.to/ed25519-20110926.pdf), and caused an exploitable bug in the Scuttlebutt protocol ([paper](https://eprint.iacr.org/2019/526.pdf), section 7.1). The [`VerifyingKey::verify()`][method_verify] function permits weak keys.
 
-The scalar component of a signature is not the only source of signature
+We provide [`VerifyingKey::verify_strict`][method_verify_strict] (and [`verify_strict_prehashed`][method_verify_strict_ph]) to help users avoid these scenarios. These functions perform an extra check on _A_, ensuring it's not a weak public key. In addition, we provide the [`VerifyingKey::is_weak`][method_is_weak] to allow users to perform this check before attempting signature verification.
-malleability, however.  Both the public key used for signature verification and
-the group element component of the signature are malleable, as they may contain
-a small torsion component as a consequence of the curve25519 group not being of
-prime order, but having a small cofactor of 8.
 
-If you wish to also eliminate this source of signature malleability, please
+## Batch verification
-review the
-[documentation for the `verify_strict()` function](https://docs.rs/ed25519-dalek/latest/ed25519_dalek/struct.PublicKey.html#method.verify_strict).
 
-## Batch Signature Verification
+As mentioned above, weak public keys can be used to produce signatures for unknown messages with high probability. This means that sometimes a weak forgery attempt will fail. In fact, it can fail up to 7/8 of the time. If you call `verify()` twice on the same failed forgery, it will return an error both times, as expected. However, if you call `verify_batch()` twice on two distinct otherwise-valid batches, both of which contain the failed forgery, there's a 21% chance that one fails and the other succeeds.
 
-The standard variants of batch signature verification (i.e. many signatures made
+Why is this? It's because `verify_batch()` does not do the weak key testing of `verify_strict()`, and it multiplies each verification equation by some random coefficient. If the failed forgery gets multiplied by 8, then the weak key (which is a low-order point) becomes 0, and the verification equation on the attempted forgery will succeed.
-with potentially many different public keys over potentially many different
+
-messages) is available via the `batch` feature.  It uses synthetic randomness, as
+Since `verify_batch()` is intended to be high-throughput, we think it's best not to put weak key checks in it. If you want to prevent weird behavior due to weak public keys in your batches, you should call [`VerifyingKey::is_weak`][method_is_weak] on the inputs in advance.
-noted above. Batch verification requires allocation, so this won't function in
+
-heapless settings.
+[fiat]: https://github.com/mit-plv/fiat-crypto
+[validation]: https://hdevalence.ca/blog/2020-10-04-its-25519am
+[func_verify_batch]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/fn.verify_batch.html
+[method_verify]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/struct.VerifyingKey.html#method.verify
+[method_verify_strict]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/struct.VerifyingKey.html#method.verify_strict
+[method_verify_strict_ph]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/struct.VerifyingKey.html#method.verify_strict_prehashed
+[method_is_weak]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/struct.VerifyingKey.html#method.is_weak

src/context.rs

@@ -15,8 +15,11 @@ use crate::{InternalError, SignatureError};
 ///
 /// # Example
 ///
-#[cfg_attr(feature = "digest", doc = "```")]
+#[cfg_attr(all(feature = "digest", feature = "rand_core"), doc = "```")]
-#[cfg_attr(not(feature = "digest"), doc = "```ignore")]
+#[cfg_attr(
+    any(not(feature = "digest"), not(feature = "rand_core")),
+    doc = "```ignore"
+)]
 /// # fn main() {
 /// use ed25519_dalek::{Signature, SigningKey, VerifyingKey, Sha512};
 /// # use curve25519_dalek::digest::Digest;

src/errors.rs

@@ -48,6 +48,7 @@ pub(crate) enum InternalError {
         length_c: usize,
     },
     /// An ed25519ph signature can only take up to 255 octets of context.
+    #[cfg(feature = "digest")]
     PrehashedContextLength,
     /// A mismatched (public, secret) key pair.
     MismatchedKeypair,
@@ -76,6 +77,7 @@ impl Display for InternalError {
                               {} has length {}, {} has length {}.",
                 na, la, nb, lb, nc, lc
             ),
+            #[cfg(feature = "digest")]
             InternalError::PrehashedContextLength => write!(
                 f,
                 "An ed25519ph signature can only take up to 255 octets of context"

src/lib.rs

@@ -113,9 +113,8 @@
 //!
 #![cfg_attr(feature = "rand_core", doc = "```")]
 #![cfg_attr(not(feature = "rand_core"), doc = "```ignore")]
-//! # use std::convert::TryFrom;
+//! # use core::convert::{TryFrom, TryInto};
 //! # use rand::rngs::OsRng;
-//! # use std::convert::TryInto;
 //! # use ed25519_dalek::{SigningKey, Signature, Signer, VerifyingKey, SecretKey, SignatureError};
 //! # use ed25519_dalek::{PUBLIC_KEY_LENGTH, SECRET_KEY_LENGTH, KEYPAIR_LENGTH, SIGNATURE_LENGTH};
 //! # fn do_test() -> Result<(SigningKey, VerifyingKey, Signature), SignatureError> {
@@ -258,6 +257,7 @@ pub use ed25519;
 #[cfg(feature = "batch")]
 mod batch;
 mod constants;
+#[cfg(feature = "digest")]
 mod context;
 mod errors;
 mod signature;
@@ -272,6 +272,7 @@ pub use sha2::Sha512;
 #[cfg(feature = "batch")]
 pub use crate::batch::*;
 pub use crate::constants::*;
+#[cfg(feature = "digest")]
 pub use crate::context::Context;
 pub use crate::errors::*;
 pub use crate::signing::*;

src/signing.rs

@@ -33,6 +33,8 @@ use curve25519_dalek::scalar::Scalar;
 
 use ed25519::signature::{KeypairRef, Signer, Verifier};
 
+#[cfg(feature = "digest")]
+use crate::context::Context;
 #[cfg(feature = "digest")]
 use signature::DigestSigner;
 
@@ -40,7 +42,6 @@ use signature::DigestSigner;
 use zeroize::{Zeroize, ZeroizeOnDrop};
 
 use crate::constants::*;
-use crate::context::Context;
 use crate::errors::*;
 use crate::signature::*;
 use crate::verifying::*;
@@ -161,6 +162,7 @@ impl SigningKey {
 
     /// Create a signing context that can be used for Ed25519ph with
     /// [`DigestSigner`].
+    #[cfg(feature = "digest")]
     pub fn with_context<'k, 'v>(
         &'k self,
         context_value: &'v [u8],
@@ -172,21 +174,15 @@ impl SigningKey {
     ///
     /// # Example
     ///
-    /// ```
+    #[cfg_attr(feature = "rand_core", doc = "```")]
-    /// # #[cfg(feature = "std")]
+    #[cfg_attr(not(feature = "rand_core"), doc = "```ignore")]
     /// # fn main() {
-    ///
     /// use rand::rngs::OsRng;
-    /// use ed25519_dalek::SigningKey;
+    /// use ed25519_dalek::{Signature, SigningKey};
-    /// use ed25519_dalek::Signature;
     ///
     /// let mut csprng = OsRng;
     /// let signing_key: SigningKey = SigningKey::generate(&mut csprng);
-    ///
     /// # }
-    /// #
-    /// # #[cfg(not(feature = "std"))]
-    /// # fn main() { }
     /// ```
     ///
     /// # Input
@@ -239,7 +235,6 @@ impl SigningKey {
     /// use sha2::Sha512;
     /// use rand::rngs::OsRng;
     ///
-    /// # #[cfg(feature = "std")]
     /// # fn main() {
     /// let mut csprng = OsRng;
     /// let signing_key: SigningKey = SigningKey::generate(&mut csprng);
@@ -250,9 +245,6 @@ impl SigningKey {
     ///
     /// prehashed.update(message);
     /// # }
-    /// #
-    /// # #[cfg(not(feature = "std"))]
-    /// # fn main() { }
     /// ```
     ///
     /// If you want, you can optionally pass a "context".  It is generally a
@@ -301,13 +293,9 @@ impl SigningKey {
     /// #
     /// # Ok(sig)
     /// # }
-    /// # #[cfg(feature = "std")]
     /// # fn main() {
     /// #     do_test();
     /// # }
-    /// #
-    /// # #[cfg(not(feature = "std"))]
-    /// # fn main() { }
     /// ```
     ///
     /// [rfc8032]: https://tools.ietf.org/html/rfc8032#section-5.1
@@ -385,13 +373,9 @@ impl SigningKey {
     /// # verified
     /// # }
     /// #
-    /// # #[cfg(feature = "std")]
     /// # fn main() {
     /// #     do_test();
     /// # }
-    /// #
-    /// # #[cfg(not(feature = "std"))]
-    /// # fn main() { }
     /// ```
     ///
     /// [rfc8032]: https://tools.ietf.org/html/rfc8032#section-5.1

src/verifying.rs

@@ -34,11 +34,12 @@ use serde::{Deserialize, Deserializer, Serialize, Serializer};
 #[cfg(feature = "serde")]
 use serde_bytes::{ByteBuf as SerdeByteBuf, Bytes as SerdeBytes};
 
+#[cfg(feature = "digest")]
+use crate::context::Context;
 #[cfg(feature = "digest")]
 use signature::DigestVerifier;
 
 use crate::constants::*;
-use crate::context::Context;
 use crate::errors::*;
 use crate::signature::*;
 use crate::signing::*;
@@ -156,6 +157,7 @@ impl VerifyingKey {
 
     /// Create a verifying context that can be used for Ed25519ph with
     /// [`DigestVerifier`].
+    #[cfg(feature = "digest")]
     pub fn with_context<'k, 'v>(
         &'k self,
         context_value: &'v [u8],