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 Oct 2014 00:13:06 -0400
From: Bill Cox <>
Subject: Re: [PHC] simplifying yescrypt

Hash: SHA1

On 10/20/2014 10:04 PM, Solar Designer wrote:
> More detail on one of the possible changes:
> On Tue, Oct 21, 2014 at 05:58:37AM +0400, Solar Designer wrote:
>> - Drop support for ROM access frequency mask.  In practice, this 
>> will mean no ROM-on-SSD support (only ROM-in-RAM will be 
>> supported).  The reason why I am considering dropping this is 
>> that in most cases where I would have recommended use of 
>> ROM-on-SSD I would _also_ recommend simultaneous use of 
>> ROM-in-RAM, and then it would need to be two ROMs, with
>> different access frequency, resulting in even greater complexity.
>> Perhaps just one mask (only for the ROM-on-SSD) would be enough
>> even in that two-ROMs case, though.
> My options are:
> 1. Leave things as-is, meaning that "large" yescrypt users (on 
> dedicated authentication servers) will have to choose either 
> ROM-in-RAM or ROM-on-SSD, but not both at once (well, except 
> possibly by chaining two invocations of yescrypt, which is a 
> suboptimal hack).
> 2. Add support for two ROMs at once.
> 3. Drop support for controlling ROM access frequency (and thus for
>  ROM-on-SSD).
> Obviously, only #3 fits the topic of this posting, but I'd like 
> this community's opinions on which option is best.  Technically, 
> I'd be able to introduce #1 or #2 in a superset of yescrypt later 
> even if I go with #3 now, so the question may be whether we want 
> ROM-on-SSD considered a supported feature in PHC context (in the 
> PHC candidate or in a currently existing superset of it).
> For ROM-in-RAM, there's normally no reason to use a mask other
> than 1, which means that 1/2 of reads (and obviously none of the
> writes) are from ROM.

Hypothetically, I can imaging going to work for some huge
corporation... like Google for instance, maybe even in their
authentication group.  In that case, if I were going to internally
promote Yescrypt based password authentication servers, it might be
the case that many of my peers know even less about password hashing
than me.

I think my first challenge would be to convince people of the value of
ROM in the first place.  That's easy - it eliminates botnet attacks.
After that, explaining why we need *two* forms of ROM, and how that
makes password hashes more secure is actually beyond my skill level
right now.

Somehow I feel we need to be able to delegate a proper password hash
with the security of Makwa, while using a 1TiB ROM to defeat botnets,
and only store a user's public key in the user database.  I was told
about the idea of only storing user public keys rather than password
hashes recently, and I think the idea has merit.  However, that means
there is a private key sitting on an average user's cell phone, and
that key needs proper pin/password protection with a good password
hashing algorithm.  I certainly hope we can use a PHC winner for that :-)

Version: GnuPG v1


Powered by blists - more mailing lists