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: Tue, 9 Dec 2014 23:32:11 +0100
From: Krisztián Pintér <>
Subject: Re: [PHC] PHC finalists announcement

since we are waiting for the decision details, why not review the
criteria meanwhile?

> - defense against GPU/FPGA/ASIC attackers

what about CPU attackers? consider a botnet or cloud computing.

> - quality of the documentation

hm. at this point, we have severe disagreement. can it be the case
that a better candidate is not selected, because a weaker candidate
was better documented? can it be the case that, provided the
competition will have an infuence on the industry practice, we will
stuck with an inferior method just because it was poorly documented

> - quality of the reference implementation

same points here. nobody ever intended to actually use the reference
implementation. it would be a shame to exclude a good algorithm due to
a subpar reference implementation.

> - general soundness and simplicity of the algorithm

i'm unclear what this means. i understand simplicity, but not general

> - originality and innovation

although i appreciate innovation, we need to understand that
innovative and good are independent concepts. an attacker will not in
any way be stopped by shining new ideas, unless they are also good.
however, an attacker might be stopped by old ideas, provided they are

let me cite at this point the original call for submissions:


Submissions will be evaluated according the following criteria:

Cryptographic security: the function should behave as a random function
Speed-up or other efficiency improvement (e.g., in terms of memory usage per password tested)
Speed-up or other efficiency improvement (e.g., in terms of area-time product per password tested)
Resilience to side-channel attacks

Overall clarity of the scheme
Ease of implementation
Use of other primitives or constructions internally

Effectiveness of the cost parameter
Ability to transform an existing hash to a different cost setting without knowledge of the password.


the final design criteria is notably different, and contains entirely
new aspects. i don't know if it changes the playing field at all, but
can be an unpleasant surprise for some authors (maybe me included,
depending on the actual scores).

Powered by blists - more mailing lists