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  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]
Date: Mon, 23 Mar 2015 19:24:15 +0100
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC: survey and benchmarks

On Mon, Mar 23, 2015 at 05:18:20PM +0100, Jakob Wenzel wrote:
> This might be ok. But they also wrote:
> 
> "We contribute to the final selection of the winners by highlighting
> the efficiency of each finalist in terms of execution time, memory
> consumption and code size."
> 
> Which does not make much sense since only the current versions are
> considered for the choice of the winner(s).

I second that for code size. Existing implementations were submitted for
reference, and in some cases for speed optimization, but I doubt any of
them was optimized for code size.

I know for a fact that the code I wrote for Makwa was deliberately
fattened with a lot of extra functionalities (e.g. Base64-like encoding,
salt generation...) and relies on OpenSSL for better portability (and
this implies non-neligible RAM usage, even though Makwa itself does not
need that much RAM). A Makwa optimized for RAM and code size, while
still maintaining decent speed optimization, will fit in about 5 kB of
code (maybe less) and less than 2 kB of RAM.

I'll wager that all the other candidates can fit in less than 10 kB code
size each. For instance, Argon uses some AES rounds, and AES encryption
can be reasonably efficiently implemented with 4 kB worth of tables; and
with AES-NI, it will use a lot less. Looking at the pseudo-code, I am
confident in claiming that Argon can be done in less than 2 kB assembly
code on recent x86 hardware. Nevertheless, the article benchmarks its
code size at a whooping 82 kB...


Of course, I can only applaud at some independent analysis on the PHC
candidates. I also quite like the "survey" part, and the efforts put
into that paper are highly commendable. I am a bit less enthused at the
"benchmark" half, because I don't really see what is measured when they
talk about speed (what sense does it make, for functions with a
configurable time cost and that aim at being slow, not fast ?), and
when code size is measured, the methodology is flaky. For a true code
size benchmark, at the very least, a common API should be defined AND
implementers should make a modicum of effort at reducing code size, e.g.
by providing an implementation for _only_ that common API.


	--Thomas Pornin

Powered by blists - more mailing lists