A pure-Rust implementation of group operations on Ristretto and Curve25519



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 x25519-dalek and 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 systems.

In particular, 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.


The semver-stable, public-facing curve25519-dalek API is documented here. In addition, the unstable internal implementation details are documented here.

The 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


To import curve25519-dalek, add the following to the dependencies section of your project's Cargo.toml:

curve25519-dalek = "3"

The 3.x series has API almost entirely unchanged from the 2.x series, except that the digest version was updated.

The 2.x series has API almost entirely unchanged from the 1.x series, except that:

  • an error in the data modeling for the (optional) serde feature was corrected, so that when the 2.x-series serde implementation is used with serde-bincode, the derived serialization matches the usual X/Ed25519 formats;

  • the rand version was updated.

See CHANGELOG.md for more details.

Backends and Features

The nightly feature enables features available only when using a Rust nightly compiler. In particular, it is required for rendering documentation and for the SIMD backends.

Curve arithmetic is implemented using one of the following backends:

  • a u32 backend using serial formulas and u64 products;
  • a u64 backend using serial formulas and u128 products;
  • an avx2 backend using parallel formulas and avx2 instructions (sets speed records);
  • an ifma backend using parallel formulas and ifma instructions (sets speed records);

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 nightly, RUSTFLAGS="-C target_feature=+avx2" to use avx2
cargo build --no-default-features --features "std simd_backend"
# Requires nightly, RUSTFLAGS="-C target_feature=+avx512ifma" to use ifma
cargo build --no-default-features --features "std simd_backend"

Crates using curve25519-dalek can either select a backend on behalf of their users, or expose feature flags that control the curve25519-dalek backend.

The std feature is enabled by default, but it can be disabled for no-std builds using --no-default-features. Note that this requires explicitly selecting an arithmetic backend using one of the _backend features. If no backend is selected, compilation will fail.


The curve25519-dalek types are designed to make illegal states unrepresentable. For example, any instance of an EdwardsPoint is 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 group.

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 x86_64 targets.

As an additional guard against possible future compiler optimizations, the subtle crate places an optimization barrier before every conditional move or assignment. More details can be found in the documentation for the subtle crate.

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 entrypoints of curve25519-dalek functions, but at the entrypoints of functions in other crates.

The implementation is memory-safe, and contains no significant unsafe code. The SIMD backend uses unsafe internally to call SIMD intrinsics. These are marked unsafe only because invoking them on an inappropriate CPU would cause SIGILL, but the entire backend is only compiled with appropriate target_features, so this cannot occur.


Benchmarks are run using criterion.rs:

cargo bench --no-default-features --features "std u32_backend"
cargo bench --no-default-features --features "std u64_backend"
# Uses avx2 or ifma only if compiled for an appropriate target.
export RUSTFLAGS="-C target_cpu=native"
cargo bench --no-default-features --features "std simd_backend"

Performance is a secondary goal behind correctness, safety, and clarity, but we aim to be competitive with other implementations.


Unfortunately, we have no plans to add FFI to curve25519-dalek directly. The reason is that we use Rust features to provide an API that maintains safety invariants, which are not possible to maintain across an FFI boundary. For instance, as described in the Safety section above, invalid points are impossible to construct, and this would not be the case if we exposed point operations over FFI.

However, curve25519-dalek is designed as a mid-level API, aimed at implementing other, higher-level primitives. Instead of providing FFI at the mid-level, our suggestion is to implement the higher-level primitive (a signature, PAKE, ZKP, etc) in Rust, using curve25519-dalek as a dependency, and have that crate provide a minimal, byte-buffer-oriented FFI specific to that primitive.


Please see CONTRIBUTING.md.

Patches and pull requests should be make against the develop branch, not master.


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.

The fast u32 and 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.

The no_std and zeroize support was contributed by Tony Arcieri.

Thanks also to Ashley Hauck, Lucas Salibian, and Manish Goregaokar for their contributions.

  • Erasing secrets from memory (zero on drop)

    Erasing secrets from memory (zero on drop)

    Yesterday @burdges mentioned some ideas about how to try to erase secret data from memory, and some things about zero-on-drop behaviour in Rust. It would be good to have a reliable way to clear secret data.

    If I understand correctly, just implementing the Drop trait to zero memory may not be sufficient, for two reasons:

    1. the write may be optimized away (see also);

    2. drop() may never be called, because Rust's memory model allows memory leaks: "memory unsafety is doing something with invalid data, a memory leak is not doing something with valid data"

    Other notes that may be of interest: this morning at RWC 2017, Laurent Simon (@lmrs2 ?) presented secretgrind.

    It could be quite convenient if Rust had a #[secret_stack] function annotation that guaranteed stack erasure, but this would require a language change.

    enhancement safety - data erasure research - rustlang 
    opened by hdevalence 22
  • u32_backend is slower than u64_backend on armv7 Android

    u32_backend is slower than u64_backend on armv7 Android

    I noticed the upcoming 4.0 release has removed the u32_backend and u64_backend features in favor of checking the target pointer size, which seems very sensible.* We know the u32_backend can be drastically faster than the u64_backend in some configurations:

    On my Xperia 10 with SailfishOS (armv7hl user space on aarch64 kernel, yes I know, rustflags = "-C target-feature=+v7,+neon"):

    • u32_backend + std: [644.25 us 646.59 us 649.28 us]
    • u64_backend + std: [6.4522 ms 6.4685 ms 6.4880 ms]

    …but not all:

    On a Cortex-M3 (Texas Instruments CC2538):

    • u32_backend without alloc: 470507 cycles
    • u32_backend with alloc (wut): 878507 cycles
    • u64_backend without alloc: 494078 cycles
    • u64_backend with alloc: 470502 cycles (the fastest)


    Today I finally got around to running some 32-bit microbenchmarks on a new Android phone (with help from a coworker), a Pixel 6a, which I feel should nonetheless still produce interesting results because, well, running armv7 code on an aarch64 device can't magically use 64-bit registers. We consistently found that the u32_backend was 5-15% slower than the u64_backend when compiling for that particular armv7.

    EDIT: Later, I tested on a 32-bit Moto X and got approximately the same results.

    All of this is differences of at most a tenth of a millisecond on any particular operation (we tested key agreement and signing + verifying), so it's not like it's going to make or break the crate. But it did make me think twice about "u32_backend is for 32-bit CPUs, u64_backend is for 64-bit CPUs". Is that worth restoring feature flags to override the default inference?

    * Especially given that the previous config made it easy for a downstream crate to depend on u64_backend implicitly as a default feature, thus removing the chance for the final program to choose the u32_backend instead.

    opened by jrose-signal 21
  • Simplifying backend selection

    Simplifying backend selection

    curve25519-dalek currently defines the following backends, modeled as crate features:

    • u32_backend
    • u64_backend
    • fiat_u32_backend
    • fiat_u64_backend
    • simd_backend
    • avx2_backend

    First, avx2_backend can be removed: it's a deprecated legacy alias for simd_backend.

    Second, I think u32_backend and u64_backend could be selected automatically by gating on e.g. cfg(target_pointer_width = "64"). If this selection were automatic, I think these features could be removed completely, with u32_backend/u64_backend selected and used by default unless another backend has been explicitly enabled.

    Likewise, fiat_u64_backend and fiat_u32_backend can be collapsed down to fiat_backend using similar target_pointer_width-based gating.

    If all of the above were done, the list above could be simplified down to just fiat_backend and simd_backend.

    opened by tarcieri 20
  • Fix nostd feature with serde enabled

    Fix nostd feature with serde enabled

    This library was previously only nostd compliant when serde was not enabled. To fix this, serde is no longer an optional dependency, but it is properly handled in both std and alloc modes. This required handling std and alloc modes separately; previously std mode included alloc. To separate these modes, it was necessary to expand a number of config checks for alloc mode to also include std.

    opened by xoloki 18
  • Intel-SA-00219 mitigations

    Intel-SA-00219 mitigations

    There are suggestions for Intel-SA-00219 mitigations at https://github.com/apache/incubator-teaclave-sgx-sdk/wiki/Mitigation-of-Intel-SA-00219-in-Rust-SGX but they make no sense:

    How would a u64 on only one side of secret data help, except by imposing 8 byte alignment? I'd think#[repr(align(8))] for types like Scalar suffices, except.. How does 8 byte alignment help if a cache line is 64 bytes?

    It treats the stack attackable, but an enclave appears trivially exploitable if it shares stack with outside code. I think some rowhammer-like attacks perform writes with numerous reads, so afaik an enclave cannot even permit outside code read access.

    Any thoughts? @tarcieri ?

    opened by burdges 17
  • Fixes `curve25519_dalek_bits` defaults for cross and wasm

    Fixes `curve25519_dalek_bits` defaults for cross and wasm

    As discussed in #456 ~~this sets well known defaults for:~~ ~~cfg(target_family = "wasm")~~ and ~~cfg(target_arch = "arm")~~

    ~~By setting the 64 bit serial arithmetric via cfg(curve25519_dalek_bits = "64")~~

    EDIT: I've used platforms crate via env TARGET to determine the actual cross target and this now fixes build.rs only.

    opened by pinkforest 15
  • Misleading description for hash-to-Edwards point

    Misleading description for hash-to-Edwards point

    The function EdwardsPoint::hash_from_bytes() is described as "performing hashing to the group" and explicitly references draft-irtf-cfrg-hash-to-curve:


    This is a rather misleading description because:

    • This function does not implement the hash-to-curve process of draft-irtf-cfrg-hash-to-curve: the hash from input to a field element is different, and the handling of the sign bit is also different.
    • Only a single Elligator2 map is applied, yielding something that draft-irtf-cfrg-hash-to-curve calls encode_to_curve, not hash_to_curve (the draft reserves the latter name for the construction that invokes the map twice, and adds together the two output points, to yield a quasi-uniform output distribution).

    The first point is mostly about interoperability; while the map is not the same as in the draft, it is still safe (in particular, this code just uses the first 255 bits of a hash output as a field element, while the draft would generate 129 extra bits and perform a modular reduction; but in Curve25519, the field modulus is very close to 2^255, so the bias from using just 255 input bits is negligible). The second point is, arguably, more important for security, because the current hash_from_bytes() produces points with a non-uniform distribution that is easy to distinguish from a uniform random generation. Most protocols (and in particular the Signal stuff that this implementation follows) don't mind, but some of them require a uniform distribution, and the lack of uniformity can have consequences ranging from invalid security proofs to actual information leaks.

    I recommend, at least, modifying the documentation to make it explicit that the implemented functionality is not compatible with draft-irtf-cfrg-hash-to-curve, and that it has a non-uniform output distribution, which may be troublesome for some (admittedly not many) protocols.

    Looking at the existing pull requests, I see PR #377, which not only modifies the description of hash_from_bytes(), but also implements (in new, additional functions) the draft-irtf-hash-to-curve process. I have not looked in details at that PR, but the idea seems good.

    opened by pornin 15
  • Switch from `clear_on_drop` to `zeroize` (fixes #281)

    Switch from `clear_on_drop` to `zeroize` (fixes #281)

    zeroize is WASM-friendly as it has no dependencies on C compilers.

    Instead uses Rust's own volatile write semantics and compiler fences to ensure zeroization is not elided by the compiler.

    opened by tarcieri 14
  • Add target u32/u64 backend overrides

    Add target u32/u64 backend overrides

    Related before-PR-doc (rendered): https://github.com/dalek-cryptography/curve25519-dalek/pull/453#discussion_r1042294155

    Thou shall ask: https://github.com/dalek-cryptography/curve25519-dalek/issues/449#issuecomment-1340670829

    Thou shall be giveth:


    Test cfg matrix / expectation

    All selected backends are mutually exclusive.


    Auto select fiat_u32 / fiat_u64 based on cfg(target_pointer_width) - default fiat_u32 on non-32/64 bits

    serial (default)

    Auto select u32 / u64 based on cfg(target_pointer_width) - default u32 on non-32/64 bits

    fiat_backend w/ cfg(curve25519_dalek_bits = "32")

    Selects fiat_u32 regardless of target_pointer on fiat_backend

    fiat_backend w/ cfg(curve25519_dalek_bits = "64")

    Selects fiat_u64 regardless of target_pointer

    serial (default) w/ cfg(curve25519_dalek_bits = "32")

    Selects u32 (serial) regardless of target_pointer

    serial (default) w/ cfg(curve25519_dalek_bits = "64")

    Selects u64 (serial) regardless of target_pointer

    opened by pinkforest 13
  • Pippenger multiscalar multiplication algorithm for very large inputs

    Pippenger multiscalar multiplication algorithm for very large inputs

    ⚠️ REPLACED BY https://github.com/dalek-cryptography/curve25519-dalek/pull/249 ⚠️

    Currently supported Straus algorithm does not improve performance as input size grows and saturates at ≈4x improvement over naïve multiplication. Pippenger’s algorithm takes advantage of very large amount of points (>190) by avoiding premultiplication of points and instead placing points in the buckets indexed by the multiplication factor. Then, buckets are cleverly added up to have their multipliers applied automatically. The process is repeated for each "digit" (that are 6 to 15 bits wide, depending on number of input points). As a result, the cost of multiplication grows slower than linearly with respect to the input size. For 1024 points Pippenger is >60% faster than Straus.

    This patch adds:

    1. An implementation of VartimeMultiscalarMul using Pippenger algorithm.
    2. Dynamic switch based on input's size_hint() from Straus to Pippenger (at 190 points).
    3. New DigitsBatch API to enumerate digits of scalars of arbitrary radix in a batch. Digits are produced via an iterator API on the fly, without pre-allocation: this allows us to have wider digits (i16) for more efficient computation of over 10K points.


    • [ ] There is no consttime version of Pippenger. It should be pretty straightforward to add (there is only one conditional point negation that depends on the value of a scalar), but I need some help in figuring this out.
    • [ ] there is no ClearOnDrop support yet.

    This addresses #130.

    opened by oleganza 13
  • Operators only implemented on references

    Operators only implemented on references

    I've noticed that operators on ExtendedPoint and the like are only implemented on &'a ExtendedPoint. Is there any reason for a PR that also implemented them for the concrete types wouldn't be accepted? The types are already copy and as far as I know the compile is better at reasoning about the code when there isn't explicit memory (i.e. a reference) involved.

    enhancement good first issue api - pain point research - rustlang 
    opened by UnlawfulMonad 13
  • Add `basepoint-tables` crate feature

    Add `basepoint-tables` crate feature

    ~~Note: depends on #488 which should be merged first.~~

    Feature-gates the inclusion of basepoint tables under a basepoint-tables feature, with the goal of reducing code size for e.g. embedded applications.

    In its current for this probably isn't sufficient to address e.g. #355 but it's a start.

    opened by tarcieri 6
  • 5.x Release strategy from 4.0.0

    5.x Release strategy from 4.0.0


    TL;DR Make 5.x a "Performance release" with good defaults whilst merging to-be-tested additions behind features e.g.:

    Breaking changes can be gated as optional within 4.x's first before making them defaults at 5.x.

    This eases testing in the wild via these "unstable features" and elevates the confidence to adopt as default(s) in 5.x.

    1. If it needs a deprecation we could always feature-gate it for 4.x as an optional additive non-breaking feature and then make it default 5.x after battletestign in the wild if so desired - like we're doing for the wasm/armv7 curve25519_dalek_bits case.

    I think for 4.0.x also we could have auto-detection for backends as an optional additive non-breaking feature auto and then make it default in 5.x.

    e.g. then this would make:

    4.0.0 was mostly paying down the maintenance techdebt that is breaking people's builds atm and causing dependnecy duplication leading to long buildtimes :partying_face:

    5.0.0 could be a performance oriented release that contains a lot of well known better defaults for performance.

    Also I've proposed some feature flags which we could include this type of work via earlier perhaps:

    • https://github.com/dalek-cryptography/curve25519-dalek/issues/287 (If we can get around LTO)
    • https://github.com/dalek-cryptography/curve25519-dalek/pull/323
    • https://github.com/dalek-cryptography/curve25519-dalek/issues/468

    We should probably collect and round-up the various features here and how to incorporate them - I'll make a list here.

    opened by pinkforest 1
  • Performance features and `#[inline]`

    Performance features and `#[inline]`

    Reviving this thread as a separate feasibility discussion around at least:

    Question 1: Should we do performance selection via features ?

    This would include perhaps providing features to maybe enable something like this this -

    • https://github.com/dalek-cryptography/curve25519-dalek/issues/287#issuecomment-552007045

    Question 2: If we provide these features would that provide confidence to impl. crate separation for backends ?

    Question 3: Is the tradeoff more around compile time for crate separation and is it relevant today ?

    Some people put these things behind a feature flag e.g. regex pointed out by BurntSushi: https://docs.rs/regex/latest/regex/index.html#performance-features

    There was some concern around LTO / cross-crate inlining I think around late 2019 and this may alleviate those ?

    Also there is now some LTO changes in 1.65: https://www.reddit.com/r/rust/comments/ycmqml/the_rust_compiler_is_now_compiled_with_thin_lto/ And some other changes.

    There was extensive chatter around #[inline] and how it works today - or a year ago?:

    • https://github.com/rust-lang/hashbrown/pull/119

    BurntSushi also pointed out a potential downside to these features - which are around build time:

    • "If we would not add any performance features like in regex which would have a side effect - "
    • "Of course, if you depend on anything that depends on hashbrown that enables the feature, then I don't think it can be turned off."

    Other than doing some feature driven [cfg_attr()] - would either generic functions work as an alternative ?

    Also are Rust inline docs today accurate -

    There is also bunch of #[inline] discussion how it works supposedly today vs docs: https://github.com/rust-lang/hashbrown/pull/119#issuecomment-537539046

    Fromn alexchrichton how #[inline] works today:

    "In release mode the compiler will, by default, codegen an #[inline] function into every single referencing codegen unit , and then it will also add inlinehint . This means that if you have 16 CGUs and they all reference a hash map, every single one is getting the entire hash map implementation inlined into it."

    Further from alexchrichton: https://users.rust-lang.org/t/enable-cross-crate-inlining-without-suggesting-inlining/55004/9

    1. "Currently #[inline] codegens it into all referencing codegen units."
    2. "For the first option we have 3 options - don't codegen into downstream crates, codegen into one CGU of any referencing downstream crate, or codegen into all CGUs. For the second we have 2 options, either apply the attribute or not."
    opened by pinkforest 1
  • Development / Maintenance / Release workflow

    Development / Maintenance / Release workflow

    I would recommend merging (no squash - to keep the history intact) from release/4.0 into main and keep the main as development branch for the next release what ever it will be in CHANGELOG.md in the branch.

    This would greatly simplify the contributions and workflows overall leading to less errors.

    This would align with the majority of the other projects contributors are used to.

    Development workflow

    I also would not use in-origin-repo branches and all the development should happen in fork(s) from where the PR's originate which will be consistent between maintainers and contributors.

    All rendered contexes should be via remote fork feature branches also for the consistnecy.

    This would also simplify the contributions and maitenance workflow and make it consistent and allows clean origin branches.

    Also GitHub makes it hard to sync fork when there is a new branch in origin.

    This all given if:

    • develop branch is redundant
    • release/x.y branches should be presented as release/x.y.z instead that get pushed into tag(s) and release
    • release/x.y.z should be immutable on which release action can create the given branch
    • backported fixes (non-breaking) should get release/x.y.z via release action automatically
    • main branch can contain all the changes regardless of the release
    opened by pinkforest 2
  • NEON backend for aarch64

    NEON backend for aarch64

    As promised in #449! This is joint work with @Tarinn. In fact, @Tarinn did most of the work :-)

    Fixes #147 for Aarch64, and you'll see an ARMv7 PR coming in after this.

    I'm working on benchmarks across several devices now (including an unpublished very hacky armv7 version), will update here when they become available. We're seeing speedups of 20-30% in relevant benchmarks. This is the same code as in https://github.com/zkcrypto/curve25519-dalek-ng/pull/19.

    I'll be cleaning up the commits in the next few minutes (trailing white space fixes, mostly), and I'll run a comparison benchmark for 343be3a, because that was only introduced for future ARMv7 support, and has not been tested under load.


    • [x] Cleanup whitespace and commits
    • [x] Test shuffle! call vs vqtbx1q_u8 performance
    • [x] Add Aarch64 cross build to CI
    • [ ] Add NEON documentation to README Explain that ARMv7 is not yet supported
    opened by rubdos 14
  • 4.0.0-pre.5(Dec 14, 2022)

    curve25519-dalek is a library providing group operations on the Edwards and Montgomery forms of Curve25519, and on the prime-order Ristretto group.

    Breaking changes in 4.0.0

    • Update the MSRV from 1.41 to 1.56.1
    • Update backend selection to be more automatic
    • Remove std feature flag
    • Remove nightly feature flag
    • Make digest an optional feature
    • Make rand_core an optional feature
    • Replace methods Scalar::{zero, one} with constants Scalar::{ZERO, ONE}
    • Scalar::from_canonical_bytes now returns CtOption
    • Scalar::is_canonical now returns Choice
    • Deprecate EdwardsPoint::hash_from_bytes and rename it EdwardsPoint::nonspec_map_to_curve
    • Require including a new trait, use curve25519_dalek::traits::BasepointTable whenever using EdwardsBasepointTable or RistrettoBasepointTable

    This release also does a lot of dependency updates and relaxations to unblock upstream build issues.

    Source code(tar.gz)
    Source code(zip)
dalek cryptography
Fast, safe, pure-rust elliptic curve cryptography
dalek cryptography
A pure-Rust implementation of Bulletproofs using Ristretto.

Bulletproofs The fastest Bulletproofs implementation ever, featuring single and aggregated range proofs, strongly-typed multiparty computation, and a

dalek cryptography 832 Dec 28, 2022
X25519 elliptic curve Diffie-Hellman key exchange in pure-Rust, using curve25519-dalek.

x25519-dalek A pure-Rust implementation of x25519 elliptic curve Diffie-Hellman key exchange, with curve operations provided by curve25519-dalek. This

dalek cryptography 252 Dec 26, 2022
Incremental hashing based on curve25519-dalek

A toy project on building an incremental hash function using the Ristretto elliptic curve for me to learn Rust. Example code from examples/main.rs: us

Alin Tomescu 2 Apr 1, 2022
A Rust implementation of the Message Layer Security group messaging protocol

Molasses An extremely early implementation of the Message Layer Security group messaging protocol. This repo is based on draft 4 of the MLS protocol s

Trail of Bits 109 Dec 13, 2022
Implementation of the BLS12-381 pairing-friendly elliptic curve group

bls12_381 This crate provides an implementation of the BLS12-381 pairing-friendly elliptic curve construction. This implementation has not been review

Zero-knowledge Cryptography in Rust 183 Dec 27, 2022
Two-party and multi-party ECDSA protocols based on class group with Rust

CG-MPC-ECDSA This project aims to implement two-party and multi-party ECDSA protocols based on class group with Rust. It currently includes schemes de

LatticeX Foundation 16 Mar 17, 2022
Multilayered Linkable Spontaneous Anonymous Group - Implemented as is from paper. Not Monero specific

MLSAG This is a pure Rust implementation of the Multilayered Linkable Spontaneous Anonymous Group construction. This implementation has not been revie

Crate Crypto 19 Dec 4, 2022
Zerocaf: A library built for EC operations in Zero Knowledge.

Dusk-Zerocaf WARNING: WIP Repo. Fast, efficient and bulletproof-friendly cryptographic operations. This repository contains an implementation of the S

Dusk Network 50 Oct 31, 2022
Lockstitch is an incremental, stateful cryptographic primitive for symmetric-key cryptographic operations in complex protocols.

Lockstitch is an incremental, stateful cryptographic primitive for symmetric-key cryptographic operations (e.g. hashing, encryption, message authentication codes, and authenticated encryption) in complex protocols.

Coda Hale 3 Dec 27, 2022
A (mostly) pure-Rust implementation of various cryptographic algorithms.

Rust-Crypto A (mostly) pure-Rust implementation of various common cryptographic algorithms. Rust-Crypto seeks to create practical, auditable, pure-Rus

null 1.2k Dec 27, 2022
A prototype implementation of the Host Identity Protocol v2 for bare-metal systems, written in pure-rust.

Host Identity Protocol for bare-metal systems, using Rust I've been evaluating TLS replacements in constrained environments for a while now. Embedded

null 31 Dec 12, 2022
An implementation of the FP-Growth algorithm in pure Rust.

fp-growth-rs An implementation of the FP-Growth algorithm in pure Rust, which is inspired by enaeseth/python-fp-growth. Usage Add this to your Cargo.t

JmPotato 13 Dec 20, 2022
A pure-Rust implementation of various threshold secret sharing schemes

Threshold Secret Sharing Efficient pure-Rust library for secret sharing, offering efficient share generation and reconstruction for both traditional S

Snips 137 Dec 29, 2022
Pure Rust implementation of the RNCryptor cryptographic format by Rob Napier

rncryptor Rust Implementation of the RNCryptor spec This library implements the specification for the RNCryptor encrypted file format by Rob Napier. d

null 7 Jun 29, 2022
Pure Rust implementation of the Leighton Micali Signature scheme.

Leighton-Micali Hash-Based Signatures LMS implementation in Rust according to the IETF RFC 8554. This implementation is binary compatible with the ref

Fraunhofer AISEC 6 Jun 2, 2022
In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

In addition to encryption library, pure RUST implementation of SSH-2.0 client protocol

陈年旧事。 73 Jan 1, 2023
Pure Rust implementation of components of the Secure Shell (SSH) protocol

RustCrypto: SSH Pure Rust implementation of components of the Secure Shell (SSH) protocol. Crates Name crates.io Docs Description ssh—encoding Decoder

Rust Crypto 27 Dec 27, 2022
Usable, easy and safe pure-Rust crypto

orion About Orion is a cryptography library written in pure Rust. It aims to provide easy and usable crypto while trying to minimize the use of unsafe

Johannes 476 Dec 22, 2022
Pure-Rust traits and utilities for constant-time cryptographic implementations.

subtle Pure-Rust traits and utilities for constant-time cryptographic implementations. It consists of a Choice type, and a collection of traits using

dalek cryptography 196 Dec 13, 2022