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

Powered by Openwall GNU/*/Linux Powered by OpenVZ