phc-discussions - Re: [PHC] Is bandwidth all that counts?

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]

Message-ID: <20140212162623.GB2098@openwall.com>
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