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: <551441F9.5050608@larc.usp.br>
Date: Thu, 26 Mar 2015 14:29:29 -0300
From: Marcos Simplicio <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
CC: Paulo Santos <pcarlos@....usp.br>
Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

On 26-Mar-15 13:27, Solar Designer wrote:
> On Thu, Mar 26, 2015 at 12:27:04PM -0300, Marcos Simplicio wrote:
>>> Lyra2 is less suitable for low sizes like this.
>>
>> Just for the sake of clarity: why exactly?
> 
> Because at too low sizes it's likely weaker than bcrypt at least
> against GPU attacks.  What exactly is "too low" is to be determined, and
> will vary by likely attacker's hardware.

Hum... That makes me think we need to include bcrypt in our GPU
benchmarks and see what happens. I'm not a GPU specialist, but we do
have a person working with the GPU implementations and the results shown
in our report (Sec. 7.3, Figure 20) are that, in the best conditions
from an attacker's perspective and for a memory usage of 2.3 MB, the
GPU-based implementation was 4.5 times slower (in terms of throughput)
than in the CPU.

Obviously, there may be some optimization missing or maybe we need have
tests with an even lower memory usage, but so far I cannot say I agree
with that impression (which does not mean you are wrong, of course).

> For scrypt at r=1 and attacks with NVIDIA Kepler GPUs, the threshold
> appears to be somewhere around 16 MB or 32 MB.  (This is from YACoin
> mining.  16 MB to 32 MB is where GPU is on par with CPU.  At lower
> sizes, some GPUs win.  For bcrypt, another GPU type is on par with CPU
> even at bcrypt's 4 KB, and Kepler is much slower than CPU, at least with
> currently available code.)

I will ask our GPU-guy to take a look at this bcrypt information. Thank you!

> 
> For Lyra2, I'd expect the threshold to be much lower, due to Lyra2's
> TMTO resistance and higher memory bandwidth usage.  1 MB feels plausible:
> it still lets an attacker pack thousands of instances per GPU card
> (maybe not quite enough to fully utilize a GPU's computing power, but
> likely enough to win over a contemporary CPU).

We will try going down from 2.3 in steps of ~1/2 and see what happens.
I'm actually very curious to know :)

Marcos.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ