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: <1045849386.20141210213944@gmail.com> Date: Wed, 10 Dec 2014 21:39:44 +0100 From: Krisztián Pintér <pinterkr@...il.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] PHC finalists announcement Tony Arcieri (at Tuesday, December 9, 2014, 11:56:16 PM): > very good reasons for not selecting particular candidates: > Emphasize CPU defense over GPU defense you got that reversed. i was calling for equal treatment for all kinds of defenses, in lieu of my earlier remark, which was that the notion that cpu is the defender and gpu/asic is the attacker platform has been brought up, and pretty much forgotten. let me bring it up again: a botnet is a cpu attacker, while a dedicated authentication server (think google or facebook sized web based services) using asics can be a defender. there is the common ground of simply having tunable cost, as opposed to specialized cost. apparently, the panel took the specialized cost approach, and i say, there need to be a rationale for that which needs disclosure. it is not obvious. you said, and we are waiting for the details, that you specifically considered gpu defense, but not cpu defense. so i assume a candidate that does not have some special anti-gpu technique scores lower. i don't think it is the right choice. > Underdocumented/poorly-specified > No good reference implementation having poor implementation or documentation is an issue easy to fix. in fact, such problems should have been pointed out much earlier, and got fixed. the primary goal is to select an algorithm. if there is any reason to believe that the selected algorithm is not the best, it is very hard to take the selection seriously. there will be a dilemma of either implementing a subpar algorithm, or implementing a less used algorithm. there should not be such a dilemma. > Unsound cryptographically i don't know how this came up. i don't remember raising any points about this, except not understanding what it means. > Doesn't offer anything novel over existing solutions it can be the case that a highly derivative approach is the best. i don't see a reason to not select a derivative algorithm if it is indeed better. > These all sound like good reasons to reject candidates to me, but i do > and I don't think the criteria have diverged from the original CFP. then please point out where documentation, originality or asic defense is mentioned in the original set of criteria. i don't think this is debatable, they are different.
Powered by blists - more mailing lists