phc-discussions - Re: [PHC] escrypt memory access speed (Re: [PHC] Reworked KDF available on github for feedback: NOELKDF)

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]

Date: Sun, 12 Jan 2014 11:58:24 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] escrypt memory access speed (Re: [PHC] Reworked KDF
 available on github for feedback: NOELKDF)

On Sun, Jan 12, 2014 at 11:43 AM, Solar Designer <solar@...nwall.com> wrote:
> On Sun, Jan 12, 2014 at 10:44:41AM -0500, Bill Cox wrote:
> And yes, I was already thinking of throwing in some multiplies.  We can
> easily do several of them one after another while waiting for data to
> arrive.  If each is 3 cycles latency not only on our CPU, but also on
> custom ASIC, then we can achieve a delay of roughly the same number of
> cycles for the attacker that we normally incur because of our memory
> latency.  The attacker's memory might have lower latency, but with the
> multiplies the attacker will be forced to slow down and match our speed.

I like that idea.  Maybe make the number of serial multiplies in the
hashing loop a parameter?  It would be simple to auto-detect a good
setting for such a parameter.  BTW, I'm sure you know this, but for a
32x32 multiply -> 32 bit result to be reversible, one of the
parameters needs to be odd.  I'm only using reversible operations in
the theory that it helps avoid leaking away entropy.  Is that all I
have to do?  It seems that if I can show that toggling any input bit
in the inputs to the hash function toggles ~half of the output bits
regardless of the other values, then when these things are cascaded,
toggling any input but should toggle ~half of all memory.  Is this the
right approach for proving the value of a hash function?

Bill