phc-discussions - auto-tuning parallelism

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-next>] [day] [month] [year] [list]

Message-ID: <20140527003639.GA9046@openwall.com>
Date: Tue, 27 May 2014 04:36:39 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: auto-tuning parallelism

Hi,

When editing the wiki page at
https://password-hashing.net/wiki/doku.php/yescrypt 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.

I'd appreciate any comments.

Alexander