A pure-Rust implementation of group operations on Ristretto and Curve25519.
curve25519-dalek is a library providing group operations on the Edwards and
Montgomery forms of Curve25519, and on the prime-order Ristretto group.
curve25519-dalek is not intended to provide implementations of any particular
crypto protocol. Rather, implementations of those protocols (such as
ed25519-dalek) should use
curve25519-dalek as a library.
curve25519-dalek is intended to provide a clean and safe mid-level API for use
implementing a wide range of ECC-based crypto protocols, such as key agreement,
signatures, anonymous credentials, rangeproofs, and zero-knowledge proof
curve25519-dalek implements Ristretto, which constructs a
prime-order group from a non-prime-order Edwards curve. This provides the
speed and safety benefits of Edwards curve arithmetic, without the pitfalls of
cofactor-related abstraction mismatches.
We have recently released a
1.0.0-pre.0 version of
would greatly appreciate testing and feedback on our API and performance.
curve25519-dalek documentation requires a custom HTML header to include
KaTeX for math support. Unfortunately
cargo doc does not currently support
this, but docs can be built using
make doc make doc-internal
curve25519-dalek, add the following to the dependencies section of
curve25519-dalek = "^0.18"
Then import the crate as:
extern crate curve25519_dalek;
nightly feature enables features available only when using a Rust nightly
compiler. It is recommended for security.
Curve arithmetic is implemented using one of the following backends:
avx2backend using parallel formulas, available when compiling for a target with
By default the
u64 backend is selected. To select a specific backend, use:
cargo build --no-default-features --features "std u32_backend" cargo build --no-default-features --features "std u64_backend" # Requires RUSTFLAGS="-C target_feature=+avx2" cargo build --no-default-features --features "std avx2_backend"
curve25519-dalek can either select a backend on behalf of their
users, or expose feature flags that control the
std feature is enabled by default, but it can be disabled for no-
--no-default-features. Note that this requires explicitly
selecting an arithmetic backend using one of the
If no backend is selected, compilation will fail.
yolocrypto feature enables experimental features. The name
is meant to indicate that it is not considered production-ready, and we do not
yolocrypto features to be covered by semver guarantees.
This is designed to make it easier to test intended new features
without having to stabilise them first. Use
yolocrypto at your own,
curve25519-dalek types are designed to make illegal states
unrepresentable. For example, any instance of an
guaranteed to hold a point on the Edwards curve, and any instance of a
RistrettoPoint is guaranteed to hold a valid point in the Ristretto
All operations are implemented using constant-time logic (no
secret-dependent branches, no secret-dependent memory accesses),
unless specifically marked as being variable-time code.
We believe that our constant-time logic is lowered to constant-time
assembly, at least on
As an additional guard against possible future compiler optimizations, the
nightly feature places an optimization barrier before every
conditional move or assignment. More details can be found in the
documentation for the
subtle crate. This is
recommended, but not required.
Some functionality (e.g., multiscalar multiplication or batch inversion) requires heap allocation for temporary buffers. All heap-allocated buffers of potentially secret data are explicitly zeroed before release.
However, we do not attempt to zero stack data, for two reasons.
First, it's not possible to do so correctly: we don't have control
over stack allocations, so there's no way to know how much data to
wipe. Second, because
curve25519-dalek provides a mid-level API,
the correct place to start zeroing stack data is likely not at the
curve25519-dalek functions, but at the entrypoints of
functions in other crates.
The implementation is memory-safe, and contains no significant
unsafe code. The AVX2 backend uses
unsafe internally to call AVX2
intrinsics. These are marked
unsafe because invoking them on a
non-AVX2 target would cause
SIGILL, but the entire backend is only
target_feature=+avx2. Some types implement an
unsafe trait to mark them as zeroable (for heap allocations), but this does
not affect memory safety.
Benchmarks are run using
# You must set RUSTFLAGS to enable AVX2 support. export RUSTFLAGS="-C target_cpu=native" cargo bench --no-default-features --features "std u32_backend" cargo bench --no-default-features --features "std u64_backend" cargo bench --no-default-features --features "std avx2_backend"
Performance is a secondary goal behind correctness, safety, and clarity, but we aim to be competitive with other implementations.
Please see CONTRIBUTING.md.
Patches and pull requests should be make against the
SPOILER ALERT: The Twelfth Doctor's first encounter with the Daleks is in his second full episode, "Into the Dalek". A beleaguered ship of the "Combined Galactic Resistance" has discovered a broken Dalek that has turned "good", desiring to kill all other Daleks. The Doctor, Clara and a team of soldiers are miniaturized and enter the Dalek, which the Doctor names Rusty. They repair the damage, but accidentally restore it to its original nature, causing it to go on the rampage and alert the Dalek fleet to the whereabouts of the rebel ship. However, the Doctor manages to return Rusty to its previous state by linking his mind with the Dalek's: Rusty shares the Doctor's view of the universe's beauty, but also his deep hatred of the Daleks. Rusty destroys the other Daleks and departs the ship, determined to track down and bring an end to the Dalek race.
curve25519-dalek is authored by Isis Agora Lovecruft and Henry de Valence.
Portions of this library were originally a port of Adam Langley's
Golang ed25519 library, which was in
turn a port of the reference
ref10 implementation. Most of this code,
including the 32-bit field arithmetic, has since been rewritten.
u64 scalar arithmetic was implemented by Andrew Moon, and
the addition chain for scalar inversion was provided by Brian Smith. The
optimised batch inversion was contributed by Sean Bowe and Daira Hopwood.
no_std support was contributed by Tony Arcieri.
Thanks also to Ashley Hauck, Lucas Salibian, and Manish Goregaokar for their contributions.
Note that docs will only build on nightly Rust until RFC 1990 stabilizes.
Various constants, such as the Ristretto and Ed25519 basepoints.
Group operations for Curve25519, in Edwards form.
Scalar multiplication on the Montgomery form of Curve25519.
An implementation of Ristretto, which provides a prime-order group.
Arithmetic on scalars (integers mod the group order).
Module for common traits.