phc-discussions - Re: [PHC] An additional PHS API to include a string?

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: <20140831142141.GA21253@bolet.org>
Date: Sun, 31 Aug 2014 16:21:41 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] An additional PHS API to include a string?

On Sun, Aug 31, 2014 at 07:31:22AM -0400, Bill Cox wrote:
> a new requirement for a function

Theoretically, there are several phases in the lifecycle of a
cryptographic algorithm chosen as part of a competition like PHC:

 1. Candidate submission (with mathematical description)
 2. Analysis/tweaking/selection
 3. Winner(s) announcement
 4. Formal specification (RFC-like)
 5. Implementation (production code)
 6. Deployment

The PHC panel, right now, promises to go to step 3; this is also what
was done in eSTREAM. For the AES and SHA-3 competition, NIST actually
includes step 4: NIST did rewrite a specification of AES, not simply
reusing what Daemen and Rijmen had written for their submission; and
for SHA-3, they are currently writing a similar standard.

Writing a formal specification is a substantial effort. You have to be
crystal-clear on all details, which can be painful (in particular,
endianness conventions at the bit level). For candidate submissions,
specifications can be shortened because they are for other researchers,
and everybody works on the same kind of PC; the reference code and the
test vectors are sufficient to solve ambiguous cases. However,
ultimately, a clean specification will be needed. Simply stating that a
specific library implementation is "the reference" is an endless source
of torment (especially if the designer unkowingly exercises one of the
subtle "implementation-defined behaviours" of C, such as right-shifting
a negative integer, or relying on modular semantics for signed
integers). On top of the writing effort, publication has a RFC (even an
"informational" RFC) adds some extra work (mostly fitting the
description in the "monospace text" format, and handling the draft
process).

As you have observed, the quality of the reference implementations, as
submitted, is not constant across candidates, in particular when it
comes to portability. Step 5 requires good implementors who are aware of
the large variability in existing architectures, and, most importantly,
such code must be _maintained_.

It is understandable that the PHC panel do not feel like producing a
formal specification, since they are people who also have jobs; and, of
course, the PHC panel is a temporary structure that, by definition,
cannot handle long term maintenance of production-level implementations.
Steps 4 and 5 are still needed, and these are tasks that need
volunteers.

With hindsight, I'd say that it would have been best if the CFP had
stated that submitters promise to write a formal specification if their
scheme happens to be selected as winner. Alternatively, an independent
body with no candidate in line (e.g. Microsoft ?) might consider doing
that work.

Personally, should Makwa be selected as (one of the) winner(s), I will
write the RFC, and do my best to maintain "production ready"
implementations.

	--Thomas Pornin