phc-discussions - Re: [PHC] Can I have two entries?

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: Sun, 23 Mar 2014 19:03:55 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Can I have two entries?

On Sun, Mar 23, 2014 at 03:29:45PM +0100, Kriszti?n Pint?r wrote:
> 
> > escrypt is just not ready for PHC yet given the full set of
> > requirements I currently have for it
> 
> that is why i recommended earlier to drop the requirement of having
> any implementation and test vectors in the first round. it should be
> theoretical, and if your algorithm is not picked, there is absolutely
> no reason to put that much effort in it.

I think having an implementation right away is very important.  It shows
that the algorithm actually exists.  I've seen papers loosely defining
some algorithm and claiming some properties for it, without convincing
me that the authors (or anyone) actually ever had that complete
algorithm and could implement it if they wanted to.  Indeed, we can
stipulate that the specification should be complete and unambiguous, but
the only reliable way to verify that is by having it in machine readable
form (as well), and this means implementation.

Test vectors could be postponed, yes, but they are relatively quick to
produce, and having test vectors early on is desirable to let us verify
that we review/test the actual scheme the way the authors intended it
(and not wasting time because of a bug).

> especially test vectors, they
> should be like the absolute last step in the standardization process,
> together with providing implementations for different platforms. these
> steps are not even needed to be done by the original author, it is
> just technicality.

Test vectors are a trivial technicality, not a burden, and they help
even early on.  (Sure, they'll change as the scheme is tweaked.)

Implementation is not as trivial, but is important to have right away.

Regardless, these are not the problems for escrypt currently.  If I
define it in a certain fixed way, I can implement that in a weekend (in
fact, I readily have implementations of each past revision of escrypt)
and generate test vectors, but that wouldn't make me happy to submit it
as-is unless it actually performs sufficiently close to "perfectly".

The "problem" is that what I have (and what I think others should have)
is an iterative process, where any slight difficulties encountered in
implementation or in optimization for a particular (common) platform or
any inefficiency on a particular (common) platform may result in
re-definition of the scheme, to make it better in those respects.  BTW,
this highlights the importance of having implementations early on.

Alexander