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]
Message-ID: <20150504211040.GA23233@openwall.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ