Nowadays, most mainstream x86 CPUs support AVX, which supports doing integer computation on 256bit. I believe that would further improve the performance.

Intel may start shipping CPUs which support AVX512 in the coming year. AVX512, as its name indicates, supports computation on 512bits. This should probably be considered as well I guess.

Hello,

This is sort of a question and a bug report at the same time.

As far as I know 2d should be ignored, and 2id used/recommended instead, as that has both GPU and side-channel attack resistance.

2i lacks the memory dependence, thus it's easily parallelizable (so less GPU attack resistance).

Could someone clarify this? (Basically the question is, does 2id suffers more from it being both data dependent, thus sort of "side-channel attack"-able, than gain from being data dependent, thus more GPU attack resistant?)

To make argon2rs #![no_std], we'd have to be able to replace all use std::*; with use core::*;. In theory, this would be as simple as doing something like this:

#[cfg(    feature = "core" )] use core::*;
#[cfg(not(feature = "core"))] use std::*;

However, as core doesn't know about threading, we'd have to do something about the lanes parameter for Argon2::new and argon2::defaults::LANES. I can think of three sensible ways to solve the parallelism issue.

1. The simplest and possibly most sensible solution would be to return ParamErr::TooManyLanes for lanes != 1. This might, however, be absolutely not what a user wants.
2. Add an extra parameter for feature = "core", which is a V-table struct for a target OS's threading API. Instead of expanding Argon2::new, however, one might just add a second Argon2::with_thread_api function. This can be combined with (1.) by returning an error if api.is_none() and lanes > 1.
3. Just ignore threading and calculate the lanes sequentially. This would, however, increase the calculation time for secure hashes by a freakin' lot. E.g., with lanes = 8 and the recommended hashing duration of half a second, doing (3.) would take four seconds for the same hash strength. This might result in feature = "core" people choosing very weak parameters.

I see the following log:

$ multirust run nightly cargo bench --features=simd
   Compiling argon2rs v0.2.1 (file:///Users/upsuper/Sources/argon2rs)
Assertion failed: (ReqTy && "extractvalue indices invalid!"), function getExtractValue, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/IR/Constants.cpp, line 2157.
error: Could not compile `argon2rs`.

Looks like a compiler bug...

My rust version:

$ multirust run nightly rustc --version
rustc 1.10.0-nightly (764ef92ae 2016-05-19)

on OS X 10.10.

The upstream implementation added a third variant of Argon2 called Argon2id. This mode provides a middle ground between the Argon2i and Argon2d modes. It provides most of the side-channel resistance of Argon2i with most of the GPU resistance of Argon2d.

For consistency with upstream this variant should be added. I might have some time this weekend to put together a PR. It shouldn't involve much; the only crypto change is in how data-dependent addressing works. It looks like that's done here.

The rest would just be adding all the additional functions, tests, and documentation.

cf. briansmith/ring#308 (comment)

It would be better if it returned an Err

        thread 'secure::test_hash' panicked at 'assertion failed: k.len() <= 32', /home/garrett/.cargo/registry/src/github.com-1ecc6299db9ec823/argon2rs-0.2.5/src/argon2.rs:195:8
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:391
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:572
   6: argon2rs::argon2::Argon2::hash_impl
             at /home/garrett/.cargo/registry/src/github.com-1ecc6299db9ec823/argon2rs-0.2.5/src/argon2.rs:195
   7: argon2rs::argon2::Argon2::hash
             at /home/garrett/.cargo/registry/src/github.com-1ecc6299db9ec823/argon2rs-0.2.5/src/argon2.rs:183
   8: novault::secure::hash
             at src/secure.rs:47
   9: novault::secure::test_hash
             at src/secure.rs:216
  10: <F as test::FnBox<T>>::call_box
             at /checkout/src/libtest/lib.rs:1480
             at /checkout/src/libcore/ops/function.rs:223
             at /checkout/src/libtest/lib.rs:141
  11: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99

Argon2::hash_impl forgets this.

To be secure, a salt is required to be universally unique across all passwords everywhere. It is very easy for a developer to do this incorrectly, which is why password hashing libraries typically generate a salt internally to take away the risk of the caller doing it incorrectly. This library should follow this pattern and generate a universally unique salt for each password internally, rather than asking the caller to provide one.

I was working on a patch to improve the readme a bit and I noticed a couple of things:

• argon2i_simple doesn't add the fields at the beginning of the hash (like $argon2i$m=4096,t=3,p=1$)
• no example for verification and verifier::Verifier::from_u8(&hash) in the example errors

The verifier expects the fields to be there afaik, is the absence expected?
Also, would you be open to a PR that adds a basic API for hashing/verifying like https://github.com/Keats/rust-bcrypt? Normal users would be able to only import {hash_password, verify_password} (which would use argon2i_simple internally) without caring about the implementation. If you want to change the passes etc you could still do it yourself

I might be missing something obvious, but does this library support password verification (i.e. argon2i_verify)? If not, are there plans to add it?

See this issue for the motivation.

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your name.

• @bryant
• @upsuper
• @vks
• @daniel-e
• @shioju
• @jimmycuadra

Add a type for hash values, impl Display for that type. The display method should print. See: https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md

Right now it is not clear what purpose the associated data serves. It would be great if it could be documented.

Unlike other cryptographic primitives, higher speeds for password hashing directly translate into improved security, as it allows the hash function to run for longer and thus linearly increases the attacker's costs. Therefore, optimizations such as the use of assembler may be justified.

RustCrypto project has a repository for password hashing algorithms. If you are interested we can transfer development of argon2rs there. I can provide necessary access to the repository if needed. (maybe also someone else will be interested in maintaining the crate?) We also can in parallel publish this crate under argon2 name.

The README mentions that the license is MIT. If you include a copy of the MIT license in your repository in a file named LICENSE, then GitHub will be able to recognize the license and tag the repository accordingly.

When you put the LICENSE file in your repository, please replace the template copyright notice with the correct year(s) of copyright as well as the name(s) and e-mail address(es) of the copyright holder(s).

Since the MIT license states that the copyright notice and the permission notice "shall be included in all copies or substantial portions of the Software", including a copy of the license in the repository with the correct copyright notice will provide the greatest opportunity for others to uphold the conditions of the license appropriately.

Why was Issue #30 closed? I don't see any such functionality in the verifier module. The Encoded struct doesn't implement fmt::Display, and it's unclear how the raw bytes are encoded, trying UTF-8 gives me an error.

I have seen that the threaded feature gate has existed for some time, which is helpful for compiling argon2rs to wasm32-unknown-unknown.

This would make it to work with errors in downstream libraries.

My first day wih Rust so I may be doing something wrong, but I get different hashes with this library than with others. Using the CLI example like this

echo "masonit" | ./target/debug/argon2test 8 1 10 0123456789ABCDEF
Hash: 24c0fe610d4eee9e3a295b04d341b434dfb170fb909817990e252f8af75d220c

But if I do this with the argon2 tool in the repositories of Ubuntu 17.10, I get a different hash:

echo 'masonit' | argon2 0123456789ABCDEF -t 8 -m 10 -p 1
Hash:		cc894b3e1345fcc3f36c0f9b808021160ec34a97441987ffb7a775bb0c34d5e8

I get the same hash as with the argon2 tool in python3, with this script:

from nacl import pwhash

password = b'masonit'
kdf = pwhash.argon2i.kdf
salt = b'0123456789ABCDEF'
Alices_key = kdf(32, password, salt,
                 opslimit=8, memlimit=1048576 )
print(Alices_key.hex())