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]

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.