Git Product home page Git Product logo

rust-argon2's Introduction

Rust-argon2

Rust library for hashing passwords using Argon2, the password-hashing function that won the Password Hashing Competition (PHC).

Usage

To use rust-argon2, add the following to your Cargo.toml:

[dependencies]
rust-argon2 = "2.1"

And the following to your crate root:

extern crate argon2;

Examples

Create a password hash using the defaults and verify it:

use argon2::{self, Config};

let password = b"password";
let salt = b"randomsalt";
let config = Config::default();
let hash = argon2::hash_encoded(password, salt, &config).unwrap();
let matches = argon2::verify_encoded(&hash, password).unwrap();
assert!(matches);

Create a password hash with custom settings and verify it:

use argon2::{self, Config, Variant, Version};

let password = b"password";
let salt = b"othersalt";
let config = Config {
    variant: Variant::Argon2i,
    version: Version::Version13,
    mem_cost: 65536,
    time_cost: 10,
    lanes: 4,
    secret: &[],
    ad: &[],
    hash_length: 32
};
let hash = argon2::hash_encoded(password, salt, &config).unwrap();
let matches = argon2::verify_encoded(&hash, password).unwrap();
assert!(matches);

Limitations

This crate has the same limitation as the blake2-rfc crate that it uses. It does not attempt to clear potentially sensitive data from its work memory. To do so correctly without a heavy performance penalty would require help from the compiler. It's better to not attempt to do so than to present a false assurance.

This version uses the standard implementation and does not yet implement optimizations. Therefore, it is not the fastest implementation available.

License

Rust-argon2 is dual licensed under the MIT and Apache 2.0 licenses, the same licenses as the Rust compiler.

Contributions

Contributions are welcome. By submitting a pull request you are agreeing to make you work available under the license terms of the Rust-argon2 project.

rust-argon2's People

Contributors

alex avatar breard-r avatar djc avatar gsquire avatar jesdazrez avatar kazcw avatar mrijkeboer avatar msrd0 avatar richardwhiuk avatar sbruton avatar sdroege avatar upsuper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

rust-argon2's Issues

Version 2.0 is unusably slow.

On a Windows 10 system with a Ryzen 9 3900x.
Compiled in debug mode takes 20 seconds to encode and 20 seconds to decode. In release mode it takes 3 seconds each. Both are unusable.

Cargo.toml

[package]
name = "argon-demo"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
rust-argon2 = "2.0.0"

src/main.rs

use argon2;
use std::time::Instant;

const PASSWORD: &str = "Test123";
const SALT: &str = "sjkdlgnldksjg";

fn main() {
    let now = Instant::now();
    // encoding
    let hash = {
        let config = argon2::Config::default();
        argon2::hash_encoded(PASSWORD.as_bytes(), SALT.as_bytes(), &config).unwrap()
    };
    dbg!(now.elapsed());

    let now = Instant::now();
    // decoding
    {
        let _ = argon2::verify_encoded(&hash, PASSWORD.as_bytes()).unwrap();
    }
    dbg!(now.elapsed());
}

output (on debug mode compilation):

C:/Users/redacted/.cargo/bin/cargo.exe run --color=always --package argon-demo --bin argon-demo
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\argon-demo.exe`
[src\main.rs:14] now.elapsed() = 19.6995189s
[src\main.rs:21] now.elapsed() = 19.0743432s

Process finished with exit code 0

Now here is the output from the exact same code but i downgraded the lib version to 1.0.1 in the cargo toml. still in debug mode

C:/Users/redacted/.cargo/bin/cargo.exe run --color=always --package argon-demo --bin argon-demo
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\argon-demo.exe`
[src\main.rs:14] now.elapsed() = 118.874ms
[src\main.rs:21] now.elapsed() = 120.0331ms

Process finished with exit code 0

just a tad bit faster

Im getting similar unusable performance compiled for release for arm64 on a raspberry pi when it was working fine on version 1.0. So this isn't some kind of super rare edgecase scenario on my windows sytem. whats going on?

[Question/Documentation Request] How long should the seed be?

This library looks to have exactly what I need, but in order to use it I need to pick a seed length (generating the seed seems easy enough via OsRng::fill_bytes in the rand crate). I'm no security expert, so I'm not really qualified to pick this length myself, and the documentation doesn't give any useful recommendations. As such, I'm wondering what it should be.

Cannot use `verify_encoded` with hashes that used a secret (and possibly associated data)

I ran into this on a project of mine, that was using a secret. Verifying passwords always failed, but when I commented out the code that added a secret to the config I used to hash the original passwords and store them, It began working correctly.

I believe the error is here https://github.com/sru-systems/rust-argon2/blob/master/src/argon2.rs#L500

I should be able to pass in the secret and ad fields. Although for this function, I think they should just be copied over

Make the Config struct self contained, to make Clone meaningful

Currently doing anything multithreaded or asynchronous with the Config struct requires you to clone and move the ad and secret variables separately. Considering the popularity of async in rust right now it would be beneficial to change the secret and ad variables in Config to Vec, making the crate easier to use in such situations.

The downsides I can see are that there is one more copy if you are running with static data from the start and that you may store the secret/ad twice.
The benefits I see are that you don't need to bother with internal lifetimes and separate structs, which gives that you can clone the Config and send it to a different thread without additional variables or just place it in an Arc and reuse it forever.

Transfer to RustCrypto?

Greetings!

In the RustCrypto organization we have a repository for password-hashing algorithms. Would you be interested in moving this crate to it? We have access to the argon2 name, so future version can be published under it.

I think it will help to attract developers and additional attention to this crate. Also if you are interested, I can invite you to the organization.

See RustCrypto/password-hashes#1 for additional context.

Setup Travis CI

Adding Travis CI integration should be trivial nowadays for a Rust project.

For this repo, you may not want to run tests with debug mode, since they are too slow... Maybe we can just skip the hash tests in debug build while keeping running unit tests in all builds.

make core module public?

I'm currently implementing RandomX for Monero in Rust (https://github.com/Ragnaroek/mithril). For this
I need the functions initialize and fill_memory_blocks from core to directly initialize the seed memory with argon2 hashes.

What are your thoughts about making the core public usable from the outside for "advanced usage"?

Feature flag for crossbeam / multithreading usage?

crossbeam is a pretty big dependency for a small crate so would be nice to be able to use this crate without bringing in all of crossbeam. Ran esp. into this with #16 where the old crossbeam version had a flagged security vulnerability in the old memoffset crate.

As ThreadMode::Sequential is default anyway, having an optional feature flag that adds the crossbeam dependency and exposes the ThreadMode::Parallel would be great and then. And not having this feature flag in the default feature listing, so crates have to opt in to the parallel crossbeam code instead if they want to use it.

Would such a change be ok? Would be a breaking change was ThreadMode::Parallel would only be exposed if the parallel feature flag is used. But would likely be ok as this crate is not at 1.0 stable yet

Test failure on s390x

I am the maintainer for rust-argon on debian. The crate builds on fine. The tests on the s390x architecture fail though. This happens because the values differ because of the way the bits are encoded on s390x. See this debian wiki entry. Please consider fixing that issue as it prevents testing migration. I attached the log below.
log.gz

Verification comparison is not constant time

This implementation's verify_raw() function doesn't make any attempt to use constant-time comparison, opening up the potential for side-channel attacks:

https://github.com/sru-systems/rust-argon2/blob/master/src/argon2.rs#L543

The reference implementation does attempt to make the comparison constant-time:

https://github.com/P-H-C/phc-winner-argon2/blob/f30e1f11f2e2619f07a4950abe1419218c4900be/src/argon2.c#L239

(As far as I can tell, the spec does not explicitly mention a requirement for this.)

SaltToShort check should be droppped.

Hello,

I am trying to write a program that derrives a AES key from a password.
The entire program has to be compatible with existing java software. I.e the java code and the rust application have to
get the same key from the same input.

The java application uses a 4 byte salt that is set to a constant value for all inputs.
This step cannot be repated using your rust library as it will always fail with Error SaltToShort.

I have verified that all other parameters are compatible and rust and java arrive at the same result by changeing the java program to use 8 byte salt. This is however not feasable as this obvieusly changes the resulting AES key for the same password.
I can obvieusly not "keep" this change in the java program as there is tons of existing data that was encrypted using 4 byte salt keys that
the new rust application now has to decrypt.

I have checked the bouncy castle java library that the java application uses for argon2 and it appears to have no check whatsoever in terms of length. It even supports passing no salt at all. This java library is very mature and has a wide adoption. (Its older than rust itself)

My suggestion is to drop all salt length checks and ensure that the outputs are the same than what the bouncy castle java library would produce.

For me personally I think just changeing the constant from 8 to 4 would already solve all my issues... However I think there are other people out there that may have used any number of bytes smaller than 4 as a "fake" salt to derrive keys from a password.

This is the relevant java code from the bouncy castle library. As you can see there are no checks concerning length.
grafik

The "null == octets" check can be ignored as you can just pass a 0 length array as parameter to bypass it.

Dependency vulnerability using `cargo audit`

Using cargo audit on a project, I get

error: Vulnerable crates found!

ID:	 RUSTSEC-2019-0011
Crate:	 memoffset
Version: 0.2.1
Date:	 2019-07-16
URL:	 https://github.com/Gilnaa/memoffset/issues/9#issuecomment-505461490
Title:	 Flaw in offset_of and span_of causes SIGILL, drops uninitialized memory of arbitrary type on panic in client code
Solution: upgrade to: >= 0.5.0

error: 1 vulnerability found!

It is being pulled in from crossbeam-epoch v0.5 - could you update your dependencies to solve it?

New crates.io release

Hi, it would be cool if you could do a new release on crates.io with the new crossbeam version. Thank you! A minor release 0.5.2 would be most prefferable.

wasm compatability?

Currently this crate is not wasm compatible due to use of threads. Would it be possible to add wasm compatability?

Clarification of field usage in Config struct

Currently the descriptions are generally no more explanatory than the variable names. Some explanation on what it does with the data or what the intended use is would be good, since your APIs may well be the first a dev sees of argon2. Proposed addition:

Associated data can be used to bind a hash to a specific use case, such as b"development". Can be argued to be redundant with secret and salt, but is a useful additional layer of safety in some cases.

Secret is the usual secret key added to the hashing process. It is highly recommended to set this to randomly generated data to prevent rainbow-table attacks. Losing/changing the servers secret key will of course invalidate all existing password hashes.

Associated data (ad), secret, salt and password are all combined together before hashing. As such they all have more or less the same influence on the resulting hash and a change to any of them will change the hash.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.