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, 12 Feb 2014 20:26:23 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Is bandwidth all that counts?

On Tue, Feb 11, 2014 at 05:47:47PM -0500, Bill Cox wrote:
> Having submitted my NoelKDF with it's multiplication compute-time
> hardening, I am now wondering if the compute time we force an attacker
> to spend matters at all.  An attacker will simply add password hashing
> cores, which are close to free, to his FPGA or ASIC, until his memory
> bandwidth is full.  If I force him to spend a full second to write and
> then read 4GiB once (which I do), he'll just run 5 of my hashing cores
> in parallel on an FPGA and fill it's 40GiB/sec memory bandwidth, doing
> 5 guesses per second, so who cares that I forced him to spend as long
> as me computing the hash?

The multiplication latency hardening was introduced (in discussions in
here) as a way to tie up as much attacker's memory for almost as much
time as the defender had to spend (per hash computed), even if the
attacker's memory bandwidth would otherwise allow for computing the
hashes faster.

So yes, it does matter.

> Now the reverse is not true - if we spend time on a complex hash
> function instead of filling memory rapidly, an attacker will be more
> efficient, maxing out his memory bandwidth while we don't, and that
> ration is pure win for the attacker.
> 
> It seems to me that the important thing is to fill memory as rapidly
> as possible, wasting as little time as feasible just doing
> computations rather than reading/writing memory.  NoelKDF is pretty
> respectable in this regard, filling memory on my development machine
> at about 5GiB with 1 thread, and 10GiB with 2 threads.  However, the
> machine is probably capable of over 20GiB/sec.

Yes, staying close to saturating memory bandwidth is desirable (albeit
less so when you have multiplication latency hardening than when you
don't), and yes you can achieve better speeds by accessing memory with
SIMD instructions.

Alexander

Powered by blists - more mailing lists