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  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: Tue, 9 Dec 2014 23:21:41 +0000
From: Marsh Ray <>
To: "" <>
Subject: RE: [PHC] PHC finalists announcement

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

From: Krisztián Pintér [] 
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.

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:

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.

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


- Marsh

Powered by blists - more mailing lists