lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2018 21:05:12 +0200
From: Solar Designer <>
Subject: Re: [PHC] Is $7$ coming any time soon?

On Wed, Mar 28, 2018 at 10:37:46AM -0700, Dean Pierce wrote:
> Does anyone know what needs to happen to get Argon2 into crypt[1]?

> [1]

We already have a crypt(3)-like encoding for Argon2, it's part of the
phc-winner-argon2 release/tree.

Whether specific implementations of crypt(3) should include its support
or not is a separate question, and I'd say it's related to whether
Argon2 significantly improves upon bcrypt or not at realistic settings
and against realistic adversaries for those use cases.  For "a few
megabytes" and against GPUs, this unfortunately does not appear to be
the case.  So maybe it'd make more sense to switch away from bcrypt once
FPGA or ASIC attacks against bcrypt become more of a problem (soon?)

For bcrypt cost 2^5 (actual you'd use now is more like cost 2^8 to 2^12,
but the scaling is almost linear), best speeds are 56k/s/GPU on the new
NVIDIA Volta instances at Amazon AWS, or 29k/s/FPGA on ZTEX 1.15y (which
is an obsolete cheap quad-FPGA board), or estimated ~300k/s/FPGA on AWS
F1 instances (with up to 8 FPGAs per instance, so ~2.4M/s/instance):

For GPU attacks on Argon2, my current expectation (from an e-mail
exchange with the author of argon2-gpu) is that the GPU will just
start to slow down at a memory size of ~32 MiB per hash, and we'll need
to get to hundreds of megabytes per hash for CPU to be faster:

(The speeds listed in the "Performance" section are currently way out of
date, and were poorly presented anyway.  So please disregard those.
I hope the author will publish the current speeds correctly soon.  I did
ping him about that just recently.)

> Maybe even $8$ and $9$ for runners up like yescrypt and Lyra2?

We previously defined $7$ for scrypt and I already use $y$ for yescrypt.
Both are supported in the recently released yescrypt 1.0.0 tree.

I think there's currently no need for anything else.

Again, as to possibly getting yescrypt (or perhaps a future cut-down
yescrypt-lite) into a system's crypt(3), that will depend on actual
need.  I expect that yescrypt will continue to fare much better than
Argon2 against GPUs, but then bcrypt is possibly not sufficiently dead
just yet (we'll need to work on that more - such as actually implement
it on AWS F1).  For now, we're targeting yescrypt for large-scale


Powered by blists - more mailing lists