phc-discussions - Re: [PHC] Compute time hardness

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: Wed, 1 Apr 2015 15:25:49 -0300 (BRT)
From: Marcos Antonio Simplicio Junior <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Compute time hardness

----- Mensagem original -----

> De: "Solar Designer" <solar@...nwall.com>
> Para: discussions@...sword-hashing.net
> Enviadas: Quarta-feira, 1 de Abril de 2015 14:34:31
> Assunto: Re: [PHC] Compute time hardness

> On Wed, Apr 01, 2015 at 03:48:40PM +0000, Gregory Maxwell wrote:
> > Was I was curious about was mostly if there were any large
> > separations
> > among the leaders of the high memory fill-rate/bandwidth
> > algorithms;
> > e.g. is one doing a much better job of making use of processor
> > resources than another which is otherwise close to in terms of
> > bandwidth. If there is a large separation it may not matter how its
> > counted.

> Of course, yescrypt is supposed to win this game, with "a large
> separation". ;-) With the current default settings, it does 6
> sequential rounds of MUL + ADD + XOR per 64 bytes processed. Per my
> previous message, that's equivalent to something like 7.5 32-bit ADD
> +
> 1 64-bit ADD + XOR, or let's say 9 32-bit ADDs, for each of those
> rounds. That's a total of ~54 sequential 32-bit ADDs per 64 bytes
> processed. (And in case MUL is somehow faster, there are also S-box
> lookups occurring in parallel with each MUL + ADD, but in sequence
> with
> the rest of processing. So there's not much room for speedup here.)

> What are the comparable numbers for Lyra2, POMELO, and Catena? I
> guess
> for Lyra2 and Catena it's 8 ADDs + 8 XORs per 128 bytes, right?

If the underlying sponge is Blake2b, I think that number is correct. With BlaMka, which replaces simple ADDs in the G function (e.g., a \gets a + b) by Latin Squares (a \gets a+b+2ab), that would be 8 MUL + 16 ADDs + 8 XORs (as usual, ignoring the shifts, and multiplication by 2, which is also a shift) per 128 bytes. 

Well, that assuming I understood the question correctly ... 

BR, 

Marcos. 

Content of type "text/html" skipped