phc-discussions - Re: [PHC] PHC finalists announcement

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: <1724294576.20141209233211@gmail.com>
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).