phc-discussions - Re: [PHC] OMG we have benchmarks

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: <CALW8-7LqbGnAaCzs6cwDmem4t2BHk1txiJRqas01hv6kKFQgdw@mail.gmail.com>
Date: Wed, 1 Apr 2015 12:24:34 +0300
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] OMG we have benchmarks

Great work! I think it is what we need.

Just there must be proper parameter choice.

For Argon2d the memory is looped over <t_cost> times, and t_cost=1 is
minimally secure and recommended.

For Argon2i the memory is looped over <t_cost> times, and t_cost=3 is
minimally secure and recommended.

For Argon the memory is looped over <2*t_cost+1> times, and t_cost=3
is minimally secure and recommended.

Argon and Argon2 do not have other parameters that affect the
performance crucially (apart from multithreading).  However, the other
schemes do, and they must be listed (number of rounds in the internal
function, specific flags, etc.). For fair benchmark comparison, the
designers must choose some recommended set of parameters, explicitly
claim its security, and yield it for measurement.

Dmitry

On Wed, Apr 1, 2015 at 12:01 PM, Milan Broz <gmazyland@...il.com> wrote:
> On 04/01/2015 10:45 AM, Solar Designer wrote:
>> On Wed, Apr 01, 2015 at 03:02:07AM -0500, Steve Thomas wrote:
>>> https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/mc_cost_2/memory_time_round.png
>>>
>>> Note I believe there might be a problem with some of it: battcrypt on 5x and
>>> POMELO on 3x and 5x. Since those algorithms don't have t_costs for those and I
>>> think they are run at lower settings.
>>>
>>> But ignoring that these are the best benchmarks I've seen since they're
>>> normalized for rounds across memory and time vs memory (instead of having t_cost
>>> or m_cost as an axis).
>>
>> Cool!  Why are these for t_cost from 2 to 5, though?  Where's t_cost 0
>> and 1?  I think only behavior with the lowest supported t_cost matters
>> for selection of a scheme, whereas exactly how higher t_cost affects the
>> behavior is merely additional information to be used for fine-tuning.
>>
>> Also, are the Lyra2 results included here for 1 or 2 threads?
>>
>> I assume the rest are for 1 thread?
>
> Well, it was just test run, but once it is already here:
> https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/mc_cost_2/memory_time_round.png
>
> - I fixed point colors, so it should now match all 4 versions.
>
> - Yescrypt has in 3 x round two more points (2GiB) - just typo in script.
> (I'll run all algs up to 8GiB but it will take long time -> later)
>
> - Lyra2 should be for 1 thread (-DnPARALLEL=1)
>
> - Parameters are according to Steve's table
> http://article.gmane.org/gmane.comp.security.phc/2550
> (also in https://github.com/mbroz/PHCtest/issues/1 )
>
> - the low memory setting is "unstable" because of RUSAGE measurement:
>   Real memory us is simple difference of getrusage(RUSAGE_SELF, ...)
>   before and after run (well, here maximum of three runs).
>
>   So for small memory allocations it can be even zero (because that process
>   already have some memory pre-allocated). My intention was to show that it
>   really have expected peak there.
>   (So it will not match your calculation exactly but it must be very close.)
>
> Graph for t_min is here (but is somehow strange)
> https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/m_cost/memory_time.png
>
> Milan



-- 
Best regards,
Dmitry Khovratovich