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  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: Tue, 21 Jul 2015 13:32:18 -0700
From: Bill Cox <>
To: "" <>
Subject: Re: [PHC] Argon2 improvement thread

On Tue, Jul 21, 2015 at 12:37 PM, Solar Designer <> wrote:

> I also support unifying the two, with a parameter.  As to making it
> tri-state (or beyond) rather than binary, I have no strong feelings.

I would prefer tri-state.  There's not much point confusing users by
allowing them to choose what % of memory to fill in one mode before
switching to the other.  50% of memory is fine, IMO, for the hybrid-state.
If we do standardize 2 APIs, default and extended, then I would have the
default be the hybrid state.  I guess I could see a good argument for the
default being equivalent to Argon2d, however, since it would simplify the
implementation in some cases.  It's nice to be able to support the default
API with simple code.

What I would not be happy about is having an Scrypt-like solution, where
the memory-filling pass is password independent, and only later passes are
unpredictable.  This solution would mean that a hybrid solution would
always have to waste a lot of time rehashing memory, rather than just
filling it in one pass, like we typically do with Argon2d.  A Yescrypt-like
solution, where a 1/3-ish second pass were unpredictable with a
cache-timing-resistant filling pass might work out well.  I'd hate to have
to run a full second pass in hybrid mode.



Content of type "text/html" skipped

Powered by blists - more mailing lists