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: <BY2PR03MB5549BAF207FBCC24EDBF9E7A7650@BY2PR03MB554.namprd03.prod.outlook.com>
Date: Tue, 9 Dec 2014 23:21:41 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] PHC finalists announcement

I'm a panel member with my "personal opinions" hat on:

From: Krisztián Pintér [mailto:pinterkr@...il.com] 
Sent: Tuesday, December 9, 2014 2:32 PM
> 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.

In a sense, the goal of a good PHF is to make it possible for the defender's
CPU environment to be the optimal one for performing the work factor.

>> - 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?

I would hope that wouldn't happen, but the quality of documentation
is important. I don't think we can assume that someone else will
come along later and invest the time into producing a
high-quality specification suitable for implementers.

It doesn't have to be a Latex formatted academic paper, but I want to ask the question:
"If I and N other software developers were to implement this function
from this specification what are the chances we would end up
with bug-free and interoperable implementations?"

>> - quality of the reference implementation
>
> same points here. nobody ever intended to actually use the reference 
> implementation.

I don't think that's a safe bet.  On the contrary, I think the first
thing that will happen is that people will port the reference
implementation to their scripting language frameworks, distro
maintainers will package it as libraries, etc.

> it would be a shame to exclude a good algorithm due 
> to a subpar reference implementation.

Read the Bcrypt paper if you haven't already. It's a great paper
about a great password hashing scheme.
https://www.usenix.org/legacy/events/usenix99/provos/provos.pdf

But observe the ambiguity it leaves for implementers wishing to
make a bug-free and compatible implementation.

Observe the lack of a portable reference implementation.

Observe the lack of a diverse set of test vectors.

Observe this CVE:
http://www.openwall.com/lists/oss-security/2011/06/20/2

IMHO, a primary goal of the PHC should be preventing such
a thing from happening.

> > - general soundness and simplicity of the algorithm
>
> i'm unclear what this means. i understand simplicity, but not
> general soundness.

The obsolete modified-DES crypt(3) is an example of a
"generally unsound" password hashing function. Basically
it sucks by modern standards, and in retrospect made some
questionable assumptions in its design.
http://linux.die.net/man/3/crypt

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

Agree.

- Marsh