Message-ID: <CAELGc4VAeWD8ZT4TmTmsqDfx75e1=xr4bDqon61cw3GnOhCR-g@mail.gmail.com>
Date: Wed, 1 Apr 2015 17:37:09 +0800
From: Hongjun Wu <wuhongjun@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] OMG we have benchmarks

>> 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
>

Content of type "text/html" skipped

Powered by blists - more mailing lists