phc-discussions - Re: [PHC] Comparing speed of entries

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: <CAMtf1Ht_L_8x8ytvncZHZWy0+9Luau1EuHYaVLWKAhv=x9v=2A@mail.gmail.com>
Date: Mon, 2 Mar 2015 13:15:10 +0800
From: Ben Harris <ben@...rr.is>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Comparing speed of entries

On 2 March 2015 at 12:30, Bill Cox <waywardgeek@...il.com> wrote:

>
> There seems to be some confusion about how to compare the speed of entries
> in the PHC.  IMO, we should:
>
> - Compare entries when using the _same_ hash function, the same number of
> rounds, and the same number of threads.
>
> With this simple rule, it is easy to see that Yescrypt is the fastest,
> Lyra2 is the second fastest.
>
>
The comparisons are more difficult for the entries that aren't 'sequential
memory hard', e.g. Catena's lambda variable. I'd like to see a
normalisation of these entries to be the number of invocations of the hash
primitive. You then have two independent variables 'memory' and 'hash
invocations' and the dependent variable is 'time' or 'bandwidth'.

Also looking at the numbers for the <= L1 and <= L2 memory sizes (for the
benchmarking machine).

Content of type "text/html" skipped