Usable, easy and safe pure-Rust crypto

Overview

orion

Tests Daily tests dudect Security Audit codecov Documentation Crates.io Safety Dance MSRV Matrix

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 code. You can read more about Orion in the wiki.

Currently supports:

  • AEAD: (X)ChaCha20Poly1305.
  • Hashing: BLAKE2b, SHA2.
  • KDF: HKDF, PBKDF2, Argon2i.
  • Key exchange: X25519.
  • MAC: HMAC, Poly1305.
  • Stream ciphers: (X)ChaCha20.

Security

This library has not undergone any third-party security audit. Usage is at own risk.

Orion uses formally verified arithmetic, generated by Fiat Crypto, for the X25519 and Poly1305 implementations.

See the SECURITY.md regarding recommendations on correct use, reporting security issues and more. Additional information about security regarding Orion is available in the wiki.

Minimum Supported Rust Version

Rust 1.52 or later is supported however, the majority of testing happens with latest stable Rust.

MSRV may be changed at any point and will not be considered a SemVer breaking change.

Crate Features

  • default/safe_api: All functionality, requires std.
  • serde: Requires either alloc or default/safe_api.
  • alloc: Argon2i in hazardous when default/safe_api is not available.
  • no_std: Implicit feature that represents no heap allocations. Enabled by disabling default features and not selecting any additional features.

More detailed explanation of the features in the wiki.

Documentation

Can be viewed here or built with:

RUSTDOCFLAGS='--cfg docsrs' cargo +nightly doc --no-deps --all-features

Tests and Fuzzing

The wiki has details on how Orion is tested. To run all tests:

cargo test

Fuzzing is done using honggfuzz-rs in orion-fuzz. See orion-fuzz on how to start fuzzing orion.

Constant-time execution tests can be found at orion-dudect and orion-sidefuzz.

Benchmarks

An overview of the performance that can be expected from Orion can be seen here.

The library can be benchmarked with Criterion as below. All benchmarking tests are located in benches/.

cargo bench

Changelog

Please refer to the CHANGELOG.md list.

Contributing

Please refer to the guidelines in CONTRIBUTING.md for information on how to contribute to Orion.

License

Orion is licensed under the MIT license. See the LICENSE file for more information.

Comments
  • XChaCha20Poly1305 streaming encryption

    XChaCha20Poly1305 streaming encryption

    This is the "hazardous" part of the secreat stream API proposed in #94.

    Things that are still missing are:

    • Documentation
    • More tests, especially with wrong inputs
    • An user friendly, "safe" API
    new feature 
    opened by snsmac 17
  • impl standard IO traits for hashing

    impl standard IO traits for hashing

    See #227.

    TODOs

    • [ ] Hashing
      • [x] implement from_reader for BLAKE2b
      • [ ] implement from_reader for sha2 (if we feel like we need to)
        • [ ] sha256
        • [ ] sha384
        • [ ] sha512
    • [ ] AEAD
      • [ ] implement seal_copy for XChaCha20Poly1305
      • [ ] implement open_copy for XChaCha20Poly1305
      • [ ] Other, non-high-level-interface methods (?)
    • [x] General
      • [x] decide whether to keep or change all these function names, like from_reader, seal_copy, open_copy

    EDIT: The scope of this PR has changed. We were going to try to fit the Read/Write impls for all of Orion's types into this PR, but then decided to split it up. #227 will keep track of all the impls.

    Now this PR implements std::io::Write for Blake2b and adds a convenience function orion::hash::digest_from_reader.

    new feature 
    opened by vlmutolo 14
  • Add high-level secret-stream API

    Add high-level secret-stream API

    Closes #103 and closes #94

    There is one link in the documentation that i can not get to work, i have marked it with a TODO.

    I'm a bit unsure if it is better to have a get_nonce method or if it is better to return Self and the Nonce in the new method.

    Tests a rather minimal for now, but i think this should be fine since its only a thin wrapper around the hazardous API

    Is it useful to expose the option to authenticate additional data? The "normal" AEAD seal function does not do it

    new feature 
    opened by snsmac 11
  • feature-gate tests that use `generate`

    feature-gate tests that use `generate`

    Description Tests currently fail with cargo test --no-default-features.

    Additional information It seems like this is happening because lots of the tests generate a random key. We could probably just feature-gate all those tests behind getrandom or maybe safe_api. Thoughts?

    • Orion features selected: default-features = false
    • Orion version: 723d9ef11c2b4e5f2f7746ffa9392c7cea5d8dbf
    • Rust version: $ rustc -V : rustc 1.56.0 (09c42c458 2021-10-18)

    We should probably also make sure the CI is testing no "no enabled features" case.

    improvement 
    opened by vlmutolo 9
  • Switch to fiat-crypto Rust crate

    Switch to fiat-crypto Rust crate

    Summary

    We use fiat-crypto code to implement various low-level cryptographic primitives. If the generated code from fiat-rust changes, it could mean there's a security vulnerability in it. An easy way to ensure we're notified of these changes would be to fail CI tests if the hash of the file(s) we use changes.

    Alternatives

    • We could set up some kind of Matrix bot that detects if the fiat-rust hash changes and posts to the Orion room. This would require maintaining the bot, though.
    new feature 
    opened by vlmutolo 9
  • Add initial serde support for relevant types

    Add initial serde support for relevant types

    Resolves #192.

    This is still a draft PR. The following items should be addressed before merging.

    • [x] No tests are currently implemented. I still have to think about what the best test cases would be. Suggestions are welcome.
    • [x] When it was available for the given type, serialization implementations use unprotected_as_bytes over the AsRef<[u8]> trait impl. Should we prefer using AsRef for consistency with types that don't have unproected_as_bytes, or is there some reason to prefer unprotected_as_bytes for its semantics? I'm leaning toward just using AsRef for everything that converts to/from byte slices. (Decided to go with AsRef.)
    • [x] All the serde-related logic is implemented here in a separate module. I've taken to doing it this way in my own projects to keep the boilerplate out of the modules for each type, but I'm happy to break it up and move the four serde implementations nearer to where the types themselves are defined. (Decided to move everything to the typedefs module.
    • [x] Another style point: I prefixed most of the types with their module names instead of importing them directly. For example, kdf::Salt instead of just Salt. I was concerned that other types may implement Salt in the future and we may add them to the serde module. This is a downside of keeping everything in one module; the names may have to be differentiated further. (Resolved by moving everything to typedefs module.)
    • [x] There's no documentation. Not even a comment in sight. I'm not sure what the usual convention is for serde documentation. I'll see what other crates do.
    opened by vlmutolo 9
  • Harden security of GitHub Actions CI/CD

    Harden security of GitHub Actions CI/CD

    Brian Smith has done some pretty interesting investigations into the default security of GitHub Actions at https://github.com/briansmith/untrusted/issues/50 and how to harden these. I'd like for us to re-trace some (if not all) of the steps there and see which can be implemented for our CI/CD.

    I was surprised to see that default permissions for GitHub Actions are read+write for a repository. We should be able to change this to read-only without breaking the current CI/CD.

    The official GitHub documentation for this: https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions

    Eg. setting read-only for an Action:

    name: action
    
    permissions:
      contents: read
    

    TODO:

    • [X] Delete the stored token once the changes are applied and if it's not used anymore
    security investigation 
    opened by brycx 7
  • Implement serde Serialize and Deserialize for relevant types

    Implement serde Serialize and Deserialize for relevant types

    Summary

    The serde::Serialize and serde::Deserialize traits are used pervasively throughout the Rust ecosystem to enable flexible (de)serialization of data. Many authors derive these types on structs using macros provided by serde. If orion's types don't support these traits, users won't be able to derive these serialization traits, and will have to resort to converting orion types before storing them in a struct for serialization.

    By implementing serde's standard traits, we enable authors to skip the mental burden and increased complexity of serializing orion types without serde.

    Scope

    At least for a first implementation, I would suggest only implementing serialization traits for types that are expected to either be stored in a database or sent to another application (e.g. over the network). This would include the following types.

    • pwhash::PasswordHash
    • hash::Digest
    • auth::Tag
    • kdf::Salt (added after suggestion below)

    Motivating Example

    My motivating example is storing a User type in a database. It would be nice to simply define a User struct, and then have it serialize to one long string using, for example, the bincode crate. This is what I would like the basic code to look like (using a fictional database API).

    use serde::{Serialize, Deserialize};
    use orion::pwhash::PasswordHash;
    
    #[derive(Serialize, Deserialize)]
    struct User {
        username: String,
        pwhash: PasswordHash,
        last_login: chrono::DateTime<Utc>,
    }
    
    fn store_user_in_db(user: &User, db: &Db) {
        db.write_bytes(&user.username, bincode::serialize(user));
    }
    
    fn retrieve_user_from_db(db: &Db) -> User {
        let bytes = db.get_bytes(&user.username);
        bincode::deserialize(bytes)
    }
    

    The PasswordHash type would serialize as a string by delegating to PasswordHash::unprotected_as_encoded.

    Without serde's types implemented, however, we would have to do one of the following.

    1. Create a separate User type that can be serialized.
    2. Implement serde manually on User and delegate the PasswordHash serialization to its unprotected_as_encoded method. Neither solution is particularly attractive.

    A separate, serializable User struct is probably the easiest of the the alternatives. It would look like this.

    // previous definitions omitted
    
    #[derive(Serialize, Deserialize)]
    struct UserSerialize {
        username: String,
        pwhash: String,
        last_login: chrono::DateTime<Utc>,
    }
    
    fn store_user_in_db(user: &User {username, pwhash, last_login}, db: &Db) {
        let user_serialize = UserSerialize {username, last_login, pwhash: pwhash.unprotected_as_encoded()};
        db.write_bytes(&user.username, bincode::serialize(to_serialize));
    }
    
    fn retrieve_user_from_db(db: &Db) -> User {
        let bytes = db.get_bytes(&user.username);
        let UserSerialize {username, pwhash, last_login} = bincode::deserialize(bytes);
        User {username, last_login, pwhash: PasswordHash::from_encoded(pwhash)}
    }
    

    It isn't terrible in terms of boilerplate, but it could start to get annoying and possibly error-prone to repeat struct definitions for several different types instead of just User.

    Implementing Serialize and Deserialize manually can be… unpleasant. Especially for anything complex, and definitely more boilerplate in any case.

    Pros of implementing Serialize/Deserialize

    • There is significant ergonomic benefit to supporting this nearly ubiquitous pair of serialization traits.
    • Users may be less likely to mistakenly reach for non-constant-time operations if they never actually (de)serialize the type themselves and just let serde do it for them. The common workflow is to deserialize some bytes or a string into the relevant type (would be User here, for example), and then to do operations on the fully featured type. This is beneficial because many of orion's types use constant-time operations for things like comparisons. It's anecdotal, but in my first example, the PasswordHash type spends very little time in its serialized state because it's so easy to deserialize into the fully featured type. Making deserialization the fast path could save users from security mistakes.

    Cons

    • The serialization functions in orion are helpfully named unprotected_* to signify that by using them, authors are relinquishing the constant-time features that orion provides. If we hide these functions in a serde::Serialize implementation, users may be more likely to mistakenly serialize a sensitive type and perform insecure operations on it. I realize that this somewhat contradicts the last "Pro" above, but they both seem like legitimate possibilities to consider.

    Additional Considerations

    • Serialization should conform to constant-time operations already in place. For example, PasswordHash should serialize as a string using the already-implemented PasswordHash::unprotected_as_encoded function.
    • We may have to add additional mechanisms for testing to ensure that all tests pass with or without the hypothetical serde feature enabled.
    new feature 
    opened by vlmutolo 7
  • More explicit struct initialization

    More explicit struct initialization

    Currently, for a given streaming context Ctx in module foo we have:

    let _: Ctx = foo::init();
    

    This PR changes this to be more explicit:

    let _: Ctx = foo::Ctx::init();
    
    improvement breaking change 
    opened by brycx 7
  • ci: bump EmbarkStudios/cargo-deny-action from 1.3.1 to 1.3.2

    ci: bump EmbarkStudios/cargo-deny-action from 1.3.1 to 1.3.2

    Bumps EmbarkStudios/cargo-deny-action from 1.3.1 to 1.3.2.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 6
  • Investigate performance regression of ChaCha20 implementation

    Investigate performance regression of ChaCha20 implementation

    The following changes in performance of ChaCha20 and related functions have been observed:

    rustc 1.41.0 (5e1a79984 2020-01-27), orion 0.15.0:

    • ChaCha20Poly1305: Input 128KiB, Throughput 419.22 MiB/s
    • XChaCha20Poly1305: Input 128KiB, Throughput 419.53 MiB/s

    rustc 1.56.0 (09c42c458 2021-10-18), orion 0.16.1:

    • ChaCha20Poly1305: Input 128KiB, Throughput 275.66 MiB/s
    • XChaCha20Poly1305: Input 128KiB, Throughput 275.19 MiB/s

    The change in performance was only observed on an Intel(R) Core(TM) i7-4790K CPU machine. No regression was found on the Raspberry Pi 2 Model B V1.1 used to benchmark. When running cargo bench with orion v0.15.0 and rustc 1.56.0 (09c42c458 2021-10-18), the same regressions are shown.

    It doesn't seem like any major changes were introduced in the ChaCha20 implementation between these versions, when inspecting git log. This, and that regression persists between different versions of Orion, tells us its most likely due to changes outside of this crate.

    Further things to investigate:

    • If the regression persists between rustc versions 1.41.0 to 1.56.0 (regression due to changes in rustc, maybe LLVM upgrades?)
    • If any changes in dependencies, could have caused this
    bug investigation 
    opened by brycx 6
  • Remove ignores of `criterion`-based RUSTSEC advisories once fixed

    Remove ignores of `criterion`-based RUSTSEC advisories once fixed

    criterion relies on atty which is unsound and also seems as if it's unmaintained. Let's see if criterion (https://github.com/bheisler/criterion.rs/issues/629) moves away from this, and if not, how else we should handle this.

    security 
    opened by brycx 2
  • Investigate whether actions-rs should be replaced

    Investigate whether actions-rs should be replaced

    We use actions-rs in our CI workflows. It is possible this is no longer fully maintained and also I have read talk about, that there exist more simple alternatives such as https://github.com/dtolnay/rust-toolchain

    investigation 
    opened by brycx 1
  • Consider adding `Eq` where possible

    Consider adding `Eq` where possible

    When #[warn(clippy::derive_partial_eq_without_eq)] is enabled, clippy will suggest to add Eq to some types. We should make sure this makes sense before we add this, because removing them later will be a breaking change.

    opened by brycx 5
  • convert newtypes to const generics

    convert newtypes to const generics

    This is still a WIP. The basic method was to define an inner type that behaves the way we want it to, e.g. with special Drop impls, etc. Then for each newtype we want to create, we create a small wrapper over the inner type, like struct Digest(Blake2bArray), and implement two small traits, essentially From and AsRef, to convert to that inner type.

    In another module, we provide more complex blanket implementations for any types that implement From and AsRef for our inner type. This allow us to, for example, auto-implement len, from_slice, etc for the newtypes without exposing the inner type (which could be hazardous for inner types like the planned PrivateArray type.

    opened by vlmutolo 14
  • Future use of `core::simd` and moving to SIMD-based vectorized implementations

    Future use of `core::simd` and moving to SIMD-based vectorized implementations

    Portable SIMD has landed in nightly Rust core::simd[1]. We should investigate if using SIMD in Orion is a viable option. For example, ChaCha20 can be vectorized[2], which could provide quite substantial performance benefits.

    What needs to be figured out:

    • What is, if there is any, the timeline for stabilization of core::simd and potentially std::simd (?)
    • Will the portable SIMD API require use of unsafe code if utilized within Orion?
    • What other primitives could benefit from vectorization? BLAKE2 is a candidate as well IIRC
    • If simd would require std for some unknown reason, do we want to consider providing vectorized implementations for safe-api only?
    • Will the portable SIMD offered by Rust be portable enough in the sense that we'd be able to remove the current portable non-vectorized implementations?
    • Would the portable SIMD be usable on all platforms we test on currently, including the non-std targets? What would the impact on WASM support be here?

    [1]: Most of the work seems to happen over here https://github.com/rust-lang/portable-simd [2]: https://eprint.iacr.org/2013/759.pdf

    help wanted investigation 
    opened by brycx 0
  • Considering removing `from_slice` from newtype APIs

    Considering removing `from_slice` from newtype APIs

    Since the introduction of serde support, most newtypes implement TryFrom<&[u8]> which simply delegates to from_slice(). This seems a bit redundant, especially if/when moving to Rust 2021 Edition, where TryFrom/TryInto are part of prelude. We could consider removing from_slice in the future and simply provide TryFrom only instead.

    breaking change investigation 
    opened by brycx 1
Releases(0.17.3)
  • 0.17.3(Dec 7, 2022)

  • 0.17.2(Aug 16, 2022)

  • 0.17.1(Jan 30, 2022)

  • 0.17.0(Nov 24, 2021)

  • 0.16.1(Nov 3, 2021)

  • 0.16.0(Mar 28, 2021)

  • 0.15.6(Feb 9, 2021)

  • 0.15.5(Oct 13, 2020)

  • 0.15.4(Sep 25, 2020)

  • 0.15.3(Aug 8, 2020)

  • 0.15.2(Jun 7, 2020)

  • 0.15.1(Mar 9, 2020)

  • 0.15.0(Feb 25, 2020)

  • 0.14.5(Jan 25, 2020)

  • 0.14.4(Aug 21, 2019)

    Changelog:

    • Reduce the amount of allocations throughout most of orion.
    • Vectorize the ChaCha20 implementation providing ~6% performance improvement for (X)ChaCha20Poly1305 and ~11.5% for (X)ChaCha20.
    • Documentation improvements.
    Source code(tar.gz)
    Source code(zip)
  • 0.14.3(Jul 31, 2019)

    Changelog:

    • Improved performance for ChaCha20Poly1305/XChaCha20Poly1305 when AAD is empty.
    • Refactoring of streaming contexts used by SHA512, BLAKE2b and Poly1305.
    • Implement PartialEq<&[u8]> for all newtypes and provide documentation for usage of such (by @vlmutolo).
    • Switched to stable rustfmt.
    • Fix use of now deprecated (since v0.1.7) getrandom errors.
    • Updated fuzzing targets in orion-fuzz.
    Source code(tar.gz)
    Source code(zip)
  • 0.14.2(Jun 10, 2019)

    Changelog:

    • Improved performance on all implementations, most notably: ~30% in ChaCha20/XChaCha20 and ~20% in ChaCha20Poly1305/XChaCha20Poly1305.
    • Updated zeroize dependency.
    • Testing WebAssembly (wasm32-unknown-unknown) support in CI.
    • Improved documentation.
    Source code(tar.gz)
    Source code(zip)
  • 0.14.1(May 27, 2019)

  • 0.14.0(May 4, 2019)

    • [Breaking change] Function as_bytes() for public newtypes are replaced with AsRef<> trait implementations. This means all as_bytes() calls need to be replaced with as_ref().

    • [Breaking change] The SecretKey for BLAKE2b is longer padded with zeroes to the length of the blocksize. Thus, the SecretKey no longer has a get_original_length() function, but the same result will be represented by the get_length() function instead.

    • [Breaking change] All calls to as_ref() and unprotected_as_bytes() return the newtypes data with what it was initialized, regardless of padding. (With the exception of HMAC)

    • [Breaking change] All calls to get_length() return the length of the newtype with what is what initialized, regardless of padding. (With the exception of HMAC)

    • [Breaking change] All newtypes that offer generate() now panic if the RNG fails to initialize of read from its source. This also means that newtype generate() functions, that do not take in a size parameter, no longer return a Result.

    • [Breaking change] ValidationCryptoError and FinalizationCryptoError have been removed. Though this doesn't mean that there is less information available, see issue here.

    • [Breaking change] Support for cSHAKE256 has been dropped, also meaning orion no longer depends on tiny-keccak. 8% decrease in unsafe code in dependencies.

    • All fuzzing targets in fuzz that used libFuzzer have been deprecated in favor of those in orion-fuzz using honggfuzz-rs.

    • Improvements to fuzzing targets in orion-fuzz.

    • Automated testing in CI, for constant-time execution.

    • Added From<[u8; C]> trait implementations for C-length fixed-sized newtypes, so that the caller may avoid using Result when not working with slices.

    • [Breaking change] Module hazardous::constants has been removed and all types made private. Only a select number of constants have been re-exported in their respective modules. See here for more information.

    • It is now strictly advised agianst using orion in debug mode, for what is meant to be production use. Using opt-level = 0 with orion, is also advised against. See security section.

    • rand_os has been replaced with getrandom.

    • Improvements to documentation examples as they no longer use .unwrap() but ? instead.

    Source code(tar.gz)
    Source code(zip)
  • 0.13.4(Apr 1, 2019)

  • 0.13.3(Mar 31, 2019)

  • 0.13.2(Mar 13, 2019)

    Changelog:

    • PBKDF2 and BLAKE2b now panic on lengths exceeding (2^32-1) * 64 and 2*(2^64-1), respectively.
    • ChaCha20 length constrictions are now equivalent to those of the RFC and panics on trying to process more than 2^32-1 keystream blocks.
    • Documentation improvements.
    • OpenSSL test vectors for BLAKE2b.

    Note: Strictly speaking, the first two changes are breaking, but because of the unlikeliness that this has an effect on anybody, they were not marked as such.

    Source code(tar.gz)
    Source code(zip)
  • 0.13.1(Feb 16, 2019)

  • 0.13.0(Feb 10, 2019)

    Changelog:

    • [Breaking change]: orion::hazardous::hash::sha512 previously used the same Digest as BLAKE2b. This is no longer the case, making it impossible to specify a non fixed-length hash as Digest with SHA512.
    • [Breaking change]: HLEN constant renamed to SHA512_OUTSIZE and SHA2_BLOCKSIZE constant renamed to SHA512_BLOCKSIZE.
    • Added POLY1305_OUTSIZE constant.
    • Improved documentation for high-level Password, SecretKey in hazardouss hmac and blake2b, as well as Password in pbkdf2 of hazardous.
    • Added AppVeyor builds and testing for Windows MSVC with Visual Studio 2017.
    Source code(tar.gz)
    Source code(zip)
  • 0.12.6(Feb 8, 2019)

    Changelog:

    • Switched to zeroize in favor of clear_on_drop, such that using orion on stable Rust no longer requires a C compiler.
    • Fuzzing with honggfuzz-rs.
    Source code(tar.gz)
    Source code(zip)
  • 0.12.5(Feb 4, 2019)

    Changelog:

    • Refactored HMAC and improved performance for PBKDF2 by ~50%.
    • Removed byteorder dependency using instead the endianness conversion functions that came with Rust 1.32.
    Source code(tar.gz)
    Source code(zip)
  • 0.12.4(Jan 30, 2019)

    Changelog:

    • Fixes a bug where hashing, with BLAKE2b, over 2^64-1 bytes of data would cause an overflowing addition on debug builds.

    • Fixes a bug where hashing, with SHA512, over 2^64-1 bytes of data would not result in the counter being correctly incremented.

    • Added property-based testing, using QuickCheck, to most of the library and improved testing for the library in general.

    • PartialEq is now implemented for orion::kdf::Salt and Nonce in both chacha20 and xchacha20.

    • Added get_length() for blake2b::Digest.

    • Updated fuzzing dependencies.

    Source code(tar.gz)
    Source code(zip)
  • 0.12.3(Jan 29, 2019)

  • 0.12.2(Jan 26, 2019)

  • 0.12.1(Jan 16, 2019)

Owner
Orion - Rust cryptography library
Easy, usable and safe pure-Rust crypto
Orion - Rust cryptography library
Safe, fast, small crypto using Rust

THE SOFTWARE IS PROVIDED "AS IS" AND BRIAN SMITH AND THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES

Brian Smith 3k Jan 2, 2023
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

Frank Denis 10.7k Jan 3, 2023
A young, simple and naive file crypto lib based on AES.

naive-file-crypto A young, simple and naive file crypto lib based on AES. The MAC implementation is not standard GCM, so it may be vulnerable. All cpu

DF_XYZ 1 Jan 16, 2022
Rust FFI bindings for StarkWare's crypto-cpp library

starkware-crypto-rs Rust FFI bindings for StarkWare's crypto-cpp library Note that currently target x86_64-pc-windows-msvc is not supported. If you're

Jonathan LEI 11 Aug 22, 2022
Cross-chain hub for Crypto Asset on Polkadot

ChainX ChainX is a community-driven project built on the next-generation blockchain framework substrate, the largest Layer-2 network of Bitcoin using

ChainX 261 Dec 28, 2022
Highly modular & configurable hash & crypto library

Octavo Highly modular & configurable hash & crypto library written in pure Rust. Installation [dependencies] octavo = { git = "https://github.com/libO

Octavo Developers 139 Dec 29, 2022
Crypto in, power out

Cipo Crypto in, power out Cipo makes it easy to let users pay for electricity for their camper-van, electric cars, boat, caravan and other high load c

Jonny Heggheim 9 Dec 9, 2022
The parser library to parse messages from crypto-crawler.

crypto-msg-parser The parser library to parse messages from crypto-crawler. Architecture crypto-msg-parser is the parser library to parse messages fro

null 5 Jan 2, 2023
A boringssl-based rustls crypto provider

boring-rustls-provider This is supposed to be the start to a boringssl-based rustls crypto provider. Status This is just a dump of me figuring out how

Jan 5 Nov 28, 2023
Convenience crate for verifying crypto-signed messages

signature-verifier This crate provide an easy way to verify Solana and Ethereum wallet-signed messages. Installation Add the crate to your Cargo.toml

Tim Plotnikov 3 Apr 2, 2024
A safe implementation of the secure remote password authentication and key-exchange protocol (SRP), SRP6a and legacy are as features available.

Secure Remote Password (SRP 6 / 6a) A safe implementation of the secure remote password authentication and key-exchange protocol (SRP version 6a). Ver

Sven Assmann 10 Nov 3, 2022
Prefix tree (ordered map and set) data structure using 100% safe Rust

PFX: A 100% safe, blob-oriented prefix tree This crate provides a prefix tree map and set data structure, implemented purely in safe Rust. The API is

Árpád Goretity  4 Apr 3, 2024
Simple node and rust script to achieve an easy to use bridge between rust and node.js

Node-Rust Bridge Simple rust and node.js script to achieve a bridge between them. Only 1 bridge can be initialized per rust program. But node.js can h

Pure 5 Apr 30, 2023
A blazingly fast and memory safe password cracker with user interface.

HashVat A blazingly fast and memory safe password cracker with user interface. HashVat runs with user interface and is capable of cracking the 1.000.0

JBLDSKY 2 Dec 6, 2022
A pure-Rust implementation of group operations on Ristretto and Curve25519

curve25519-dalek A pure-Rust implementation of group operations on Ristretto and Curve25519. curve25519-dalek is a library providing group operations

dalek cryptography 611 Dec 25, 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
Pure Rust implementations of the key-committing (and context-committing) AEADs

kc-aeads Pure Rust implementations of the key-committing (and context-committing) AEADs defined in Bellare and Hoang '22. Crash course on the paper: T

Michael Rosenberg 2 Aug 10, 2022
An efficient, robust, and generalized batch submission service for rollup stacks written in pure rust.

archon is an efficient, robust, and generalized batch submission service for rollup stacks written in pure rust. Note Archon is primarily tested again

refcell.eth 75 Apr 2, 2023
A blazing fast, type-safe template engine for Rust.

markup.rs A blazing fast, type-safe template engine for Rust. markup.rs is a template engine for Rust powered by procedural macros which parses the te

Utkarsh Kukreti 209 Dec 24, 2022