phc-discussions - simplifying yescrypt further

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

Date: Tue, 5 May 2015 00:10:40 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: simplifying yescrypt further

Some interest in simplified yescrypt, with no specifics, has been
expressed on the PHC panel list.  I think it's best if I post my
thoughts in here.

There are two major kinds of possible simplifications to yescrypt I am
aware of: reduced functionality (what I called yescrypt-lite) or/and
moving from SHA-256 and Salsa20 to BLAKE2b and BLAKE2b single round (and
consequently dropping scrypt compatibility mode).

If PHC chooses to promote any kind of simplified yescrypt in any way
(a winner or a recommendation), I guess it'd be up to the PHC panel to
request (or choose from a list that I may post in here) which kinds of
simplifications they'd like to see.

"Moving from SHA-256 and Salsa20 to BLAKE2b and BLAKE2b single round" is
a significant enough change that I felt it wouldn't have been a mere
tweak (and besides there's some value in scrypt compatibility, and in
ease of upgrading existing scrypt implementations to yescrypt), but if
we accept Argon2, then I guess anything goes if the PHC panel chooses
so, and this is sort of fine.  BTW, this change will have only minor
impact on yescrypt's performance and actual security properties
(including both attack/defense cost ratios and cryptographic security).
That's since most processing time is normally spent on pwxform and
waiting for memory.  However, unless this whole thing gets standardized
by NIST, there may be concerns that cryptographic security of the
resulting scheme would no longer depend on NIST-approved crypto.

Alexander