lists.openwall.net   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 <solar@...nwall.com>
To: discussions@...sword-hashing.net
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] http://man7.org/linux/man-pages/man3/crypt.3.html

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):

https://twitter.com/solardiz/status/959137089727188992

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:

https://gitlab.com/omos/argon2-gpu

(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
deployments.

Alexander

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ