phc-discussions - Re: [PHC] Added "lanes" and 3 hash functions as inputs

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

Message-ID: <20140319100934.GA6424@openwall.com>
Date: Wed, 19 Mar 2014 14:09:34 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Added "lanes" and 3 hash functions as inputs

Bill,

On Wed, Mar 19, 2014 at 01:45:47PM +0400, Solar Designer wrote:
> On Tue, Mar 18, 2014 at 07:46:29PM -0400, Bill Cox wrote:
> > I still feel like a pluggable large memory block hash function would
> > be a good thing, but if mine's the only one to do such a thing,
> > there's not really much point.
> 
> Doesn't escrypt have a large block multi-lane hash function like this?

Oh, you probably meant a hash function for mixing data between the
lanes.  If so, escrypt's pwxform is not it.  escrypt uses one or
multiple invocations of Salsa20 for this.  It's multiple if the combined
width of the many lanes is greater than 512 bits.

As currently defined in escrypt, data propagates between the 512-bit
subsets of the combined width only in one direction, except via j, which
is taken from the last 512-bit, yet affects what happens for the entire
combined width in the next block.  Maybe extra back-propagation should
be added, such as for a similar construction to be secure without
password-dependent lookups yet with higher than 512-bit combined lane
width.  (The current pwxform is not to be used without
password-dependent lookups anyway, because it does such lookups from
the S-boxes on its own.)

Alexander