Date: Thu, 2 Apr 2015 11:05:58 +0800
From: Hongjun Wu <wuhongjun@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] OMG we have benchmarks

Dear Dmitry,

I see.

I agree with you that the schemes with several parameters need to list the
parameters being used.

Further, I think that it is better for the designers to fix those
parameters in the competition.  Otherwise, the parameters can be tuned to
favor one type of comparison, then get tuned to favor another different
type of comparison.

Best Regards,
hongjun

On Wed, Apr 1, 2015 at 5:38 PM, Dmitry Khovratovich <khovratovich@...il.com>
wrote:

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

Content of type "text/html" skipped

Powered by blists - more mailing lists