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: Thu, 13 Mar 2014 17:19:57 -0400
From: Bill Cox <>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On Thu, Mar 13, 2014 at 4:27 PM, Solar Designer <> wrote:
> scrypt was designed not to bump into the memory bandwidth, at least
> not when running only one thread.  At 8 rounds of Salsa20, it stays
> below saturating memory bandwidth on typical PC hardware (albeit for
> reasons other than what you give: it tries to have its "time" factor
> based on computation effort rather than on bandwidth).  OK, you said
> "scrypt-like", and yes some scrypt-like PHC candidates will deliberately
> use more memory bandwidth than scrypt does.

I suspect I'm the leading contender for bandwidth hogging per thread :-)

However, that is easily tuned.  One thread on my machine takes up
about 9GiB/s, on a machine with about 25 GiB/s max.  Two threads take
12.1 GiB/s, and are fighting each other over bandwidth at that point,
or they would run faster.  However, with multiplications set to max,
single thread bandwidth drops to 4.5 GiB/s, and with the repetitions
parameter, you can switch the load from external memory hashing to
internal cache hashing smoothly.

However, I do get a kick out of bringing my PC to it's knees with only
two threads :-p

>> (Or, said more succintly: if you want to engage in a sports contest, and
>> you are 5' tall, then don't choose basketball.)
> Makes sense, but I think it primarily means that we shouldn't compete
> with attackers solely in terms of memory bandwidth per se.  The reason
> why TwoCats and escrypt use more memory bandwidth (than scrypt) is that
> they want to use more RAM within the allotted time (and discourage
> TMTO).  More RAM means more ASIC die area.  (For EARWORM, this is
> different.  Being ROM-only, it actually competes solely in terms of
> memory bandwidth, which is a drawback.)
> Alexander

I do think (since we discussed it on this forum recently) that a
decent defense is to try and hit the internal cache bandwidth.  Maxing
out L1 cache bandwidth sounds like a great way to compute-time harden
a PHS.  If an algorithm at the same time uses a significant portion of
L2/L3, like 10 MiB or more (as Catena originally suggested), you can
tie up some expensive real estate for some significant time.

I know there are legitimate cases for running as low in memory as
Bcrypt does, but I would avoid it whenever possible.  Cache RAM is
expensive by the MiB, but it turns out to be a whole lot cheaper on an
ASIC by the KiB :-)


Powered by blists - more mailing lists