phc-discussions - Re: [PHC] Lyra2 initial review

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: Thu, 17 Apr 2014 22:53:15 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Lyra2 initial review

On Thu, Apr 17, 2014 at 01:42:01PM -0300, Marcos Antonio Simplicio Junior wrote:
> Actually an explanation would be really good, because I confess that, except for "memory bandwidth", I'm not sure I understand what those numbers mean or how to computed them... 

Does the "memory bandwidth" figure for Lyra2 look correct to you, given
the "time" output Bill posted?

As to peak and average memory usage "per second", they're abstractions
obtained by dividing actual peak memory usage by actual running time
(for peak memory usage "per second") and averaging memory usage for a
hash computation over time and then dividing by the time it took to
compute a hash (for average memory usage "per second").  They are not
literally "per second", because they are for certain cost settings that
don't result in a hash computation taking exactly one second and because
they would not stay exactly the same for other cost settings.

Given this explanation, do these figures for Lyra2, as Bill posted given
the "time" output, look correct to you?

Is it expected that Lyra2's average memory usage is 3/4 of peak?
I think Bill may have taken scrypt's ratio for these and applied it to
Lyra2 and yescrypt, even though at least for yescrypt's native mode with
t=0 it's wrong (maybe it's also wrong for Lyra2).

> > I am surprised that Lyra2 and TwoCats seem to win significantly in
> > terms
> > of bandwidth usage. I doubt it's the cost of one round of pwxform
> > (although to find out we can try making it zero rounds, even). It
> > could
> > be the cost of r=8.
> 
> It is likely to have a relationship: we have a compile-time parameter "nCols" that has a similar effect to scrypt's "r". It is part of the algorithm's core rather than a "tweak", but it would not fit in the PHS interface... 

What did you set "nCols" to, and what does it correspond to in bytes?

[ye]scrypt's r=8 is 1 KiB.

Alexander