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

Powered by blists - more mailing lists