Date: Wed, 1 Apr 2015 12:38:25 +0300
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] OMG we have benchmarks

I apologize, I meant "some other schemes".

Dmitry

On Wed, Apr 1, 2015 at 12:37 PM, Hongjun Wu <wuhongjun@...il.com> wrote:
>>> 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.).
>
> ....... I think there is some typo in the message above.  POMELO is not one
> of "the other schemes".
>
> POMELO does not have other parameters that affect the performance.  More
> specifically, the performance of POMELO is only affected by m_cost and
> t_cost   (so there is no multiple algorithms, no multi-threading, no number
> of rounds, no specific flags, etc ...)
>
> Best Regards,
> hongjun
>
>
>
> On Wed, Apr 1, 2015 at 5:24 PM, Dmitry Khovratovich <khovratovich@...il.com>
> wrote:
>>
>> 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
>
>



-- 
Best regards,
Dmitry Khovratovich

Powered by blists - more mailing lists