phc-discussions - Re: [PHC] Competition process

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: <20150414141913.GA2838@openwall.com>
Date: Tue, 14 Apr 2015 17:19:13 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Competition process

On Tue, Apr 14, 2015 at 01:01:54PM +0000, Gregory Maxwell wrote:
> I've personally felt that there is no win here... that there are
> elements of each candidate that I consider superior which are not
> incompatible and only do not exist in a single proposal due to how the
> history panned out.

For many finalists, yes.  But for yescrypt in particular, there's only
one desirable property it's lacking that isn't strictly incompatible
with those it does have: cache timing safety.  While adding cache timing
safety is incompatible with some of yescrypt's current elements, it can
nevertheless reasonably be made an option (disabling those elements).
In fact, I might add this option later (as a non-PHC extension, given
that we have no further tweaks planned in PHC).

Are you aware of anything else that yescrypt could have had, but is
lacking only "due to how the history panned out"?

yescrypt is being criticized primarily for being overly(?) complex, and
this is in fact related to it being that almost all-in-one solution.
(It could be slightly simpler, yet with all of its present features, if
I started over without the scrypt legacy.  But only slightly.)

Makwa's delegation is probably not something that could reasonably be
added to the mix of what's currently in yescrypt.  It'd probably double
the complexity, so these may be better as independent schemes that can
be used together whenever that makes sense in a given protocol.

> Some might think that this fact is a reason to select many winners;
> but I think many winners is pessimal for the marketplace.  There is so
> much that any of the candidates can be improved through really
> excellent implementation which is diluted by multiple options, there
> is compatibility lost, etc.

There are definitely major drawbacks to having multiple winners with
overlapping use cases.

So far, I tried to provide for a workaround by defining yescrypt such
that cut-down partial functionality implementations make sense, and are
significantly simpler.  (We need to actually produce some of these, to
demonstrate that.)  The PHC panel might or might not find this
workaround "good enough" (so it might or might not select yescrypt), but
I'm afraid our alternatives are either to select another single winner
that isn't an all-in-one, or to select multiple winners.

None of these three options (all-in-one winner, non-all-in-one winner,
multiple winners) is perfect.

Alexander