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: Sat, 11 Jan 2014 14:41:31 -0800
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] escrypt memory access speed (Re: [PHC] Reworked KDF
 available on github for feedback: NOELKDF)

On Sat, Jan 11, 2014 at 1:42 PM, Bill Cox <waywardgeek@...il.com> wrote:
> On Sat, Jan 11, 2014 at 2:23 PM, Solar Designer <solar@...nwall.com> wrote:
>>>
>>> 48.95 GB/s * 2 rounds = 97.90
>>> 45.63 GB/s * 4 rounds = 182.52
>>> 38.03 GB/s * 8 rounds = 304.24
>>> 30.43 GB/s * 12 rounds = 365.16
>>> 19.93 GB/s * 20 rounds = 398.60
>
> Imagine that all the lines of code you've written in C for escrypt,
> other than for memory access, will cost an attacker maybe $0.02 per
> core, and that Salsa20/20 will run in maybe 2 clocks instead of 1 for
> Salsa20/1.  This is roughly the case, within maybe 2X in cost and
> clock cycles.  It's pointless trying to make an ASIC attacker's
> arithmetic cost significant in either time or money, so we have to
> focus on memory size and bandwidth.  For defense against ASIC attacks,
> your Salsa20/1 benchmark is the best.  50GB/s!  Nice!

Is this entirely true?  That is, I always thought that the fancy ALUs
on modern CPUs were big and expensive, and that they accounted for
non-negligible fractions of the cost.  If so, that would mean that a
good password hash should try to max them out.  There's also cache
size and bandwidth, and I assume that sticking really fast cache on an
ASIC is just as expensive as the really fast cache that already exists
on CPU dies.

(I could be wrong here.  I've fiddled with high-end Virtex parts, but
I have no real concept of what ASIC logic costs.)

--Andy