[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1026474646.20150323192904@gmail.com>
Date: Mon, 23 Mar 2015 19:29:04 +0100
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC: survey and benchmarks
Jean-Philippe Aumasson (at Monday, March 23, 2015, 3:07:34 PM):
> This just appeared: http://eprint.iacr.org/2015/265
i'm very happy to have more analysis. however, i find some data
questionable in this article.
no page 20, they claim that gambit uses 67-103kb ram for the code,
excluding the ram needed for the stretching itself. i doubt that ANY
candidate needs even one kilobyte of code, but sure not two. this
number is entirely bogus. i can only assume they measured the complete
compiled program size, which includes the c runtime and in many case,
some main program.
later they make claims about many candidate's ram and time
requirement, which is weird, because it is often tunable. in
particular, gambit can use any amount of memory and time (with some
interdependence), so these claims are false. the same is true for
almost all candidates, except the few peculiar ones that does not use
ram as cost.
in the measurement data table, i don't get the parameter selection
logic. some candidates are relatively well covered from low to high
memory and time (maybe even over it, argon's 577 second runtime seems
overkill :) ). however, with other candidates, the parameter coverage
entirely falls far outside the intended range.
maybe i just don't understand something, but i have the impression
that the authors had problems finding information about useful
parameter ranges? maybe it would be helpful to assemble a table
containing parameter-cost values for each candidate.
Powered by blists - more mailing lists