| 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
| ||
|
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).
Powered by blists - more mailing lists