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: Tue, 9 Dec 2014 23:32:11 +0100
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
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
once?

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

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


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

------------------8<---------------------

Submissions will be evaluated according the following criteria:

Security
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

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

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

------------------8<---------------------

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