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, 27 May 2014 07:44:04 -0700
From: Andy Lutomirski <>
To: discussions <>
Subject: Re: [PHC] auto-tuning parallelism

On Mon, May 26, 2014 at 5:36 PM, Solar Designer <> wrote:
> Hi,
> When editing the wiki page at
> yesterday, I added
> this (which has been in my head for months) to "Drawbacks":
> "While pwxform's default 4x 128-bit SIMD parallelism fits SIMD-enabled
> builds running on modern CPUs well, it is excessive for older CPUs and
> non-SIMD builds, making such slower builds of yescrypt weaker than
> similar builds of bcrypt in terms of GPU attack resistance (when
> yescrypt's memory usage is low)
> Using much lower parallelism settings when appropriate should address
> this, but the risk of people (inadvertently?) using a high SIMD- and
> instruction-level parallelism mode in a build not suitable for that will
> remain"
> Here's an idea on how to deal with this: besides possibly supporting
> explicit specification of the desired SIMD- and instruction-level
> parallelism as input parameters to yescrypt, support a magic input value
> or a flag that would request the current build's optimal settings.  When
> invoked like this, e.g. yescrypt-opt.c (scalar) would use settings for
> one 64-bit lane, whereas yescrypt-simd.c would use 4x 128-bit SIMD.
> Indeed, this will affect the computed hash value, so it's only usable
> when setting a new password or initially encrypting some data, and the
> actual parallelism settings would need to be output by yescrypt and
> encoded along with the hash or derived key.
> This fits nicely in the currently defined yescrypt_gensalt*() API -
> they'd generate salt strings optimal for the current build of yescrypt,
> when requested to do that by a flag.  Those salt strings will have the
> actual parallelism settings encoded in them.
> Unfortunately, it doesn't fit nearly as well into other APIs - those
> that don't use ASCII strings for salts+hashes.  Should this feature be
> limited to the crypt(3)-like strings-based APIs, or should it somehow be
> added to (binary) key derivation APIs as well?  I'd do both, but I'm
> concerned it might not be intuitive for non-strings-based APIs.

For the binary case, it might be simpler to have a second function to
call to ask for good parameters.  Then the caller can, for example,
call it once, hash a bunch of passwords, and know that they have the
same parameters (and therefore not store a copy for each password).


Powered by blists - more mailing lists