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  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: 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

Powered by blists - more mailing lists