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: <20141210015419.GA1156@bolet.org>
Date: Wed, 10 Dec 2014 02:54:19 +0100
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC finalists announcement

On Tue, Dec 09, 2014 at 11:21:41PM +0000, Marsh Ray wrote:
> 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.

To be even more accurate, the goal of a good PHF is to make the
defender's environment the most _cost effective_ one for performing the
work factor. Ultimately it is all about the money.

A few months ago someone claimed on this list that password hashing was
more about engineering than cryptography; in my opinion, it is more
about economics than anything else. The attacker will balance the cost
of running the attack, in terms of both buying the hardware and running
it, against the gain expected from a successful password recovery. The
defender wins if the balance is such that the attacker won't try.


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

I totally second that. One of the psychological effects at work here is
that many people feel that the "official" implementation is in some way
better than any other, since it is imbued with the radiance of the
inventor (many developers have a relatively poor grasp of what
"deterministic function" really means).

In fact it has already begun; e.g. see: https://github.com/buggywhip/PHC

That's the reason why I never publish code that is not already
"production ready". Regardless of how many "for research only" warnings
you put up, people _will_ take the code and deploy it.


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

It is also a general convention of Science and other intellectual
fields, since at least the days of Confucius, to require clear
exposition from the proponent of any idea. Disregarding poorly expressed
proposals is the normal way of working for academics; it does incur the
risk of missing on some genius with poor communication skills, but it
saves a lot of time and thus tends to be a net gain for Science in the
long term.

In the specific case of password hashing functions, the heart of the
problem is about implementation efficiency, in particular how the
defender's hardware (presumably a general purpose CPU) will be optimal
for implementation of attacks (economic optimality, see above). Thus, it
somehow makes sense to require from candidate proponents to demonstrate
some reasonable level of skill in implementation, as a kind of proof
that they know what they are talking about. This is of course a bit
unfair and not a 100% reliable test of quality for an algorithm,
especially since making _fast_ code and making _portable_ code exercise
distinct skill sets. But it is still logical.

Thus, quality of the reference implementation is a legitimate criterion
_among others_. And this is not a novelty; this has been the case for
all cryptographic competitions, all cryptologic research, and, in a
general sense, all academic thinking for a very long time. (Socrates was
very lucky to have Plato as disciple.)


	--Thomas Pornin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ