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: Fri, 30 Jan 2015 15:19:26 +0100
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] PHC finalists tweaks (SUBMITTERS, please read carefully)

Substantial changes to a submission would complicate the work of the
panel: imagine that 2 weeks before announcing the decision, a
candidate adds new features, drop some others, etc.

What is of course acceptable are editorial changes to the document,
new or improved implementations.

On Fri, Jan 30, 2015 at 3:07 PM, Solar Designer <> wrote:
> On Tue, Dec 09, 2014 at 03:38:54PM +0100, Jean-Philippe Aumasson wrote:
>> Submitters of a finalist are now given a chance to make minor changes
>> to their algorithm: Submitters have until January 31, 2015 to submit
>> the final version of their algorithm. If the final version is
>> identical to the current version, submitters don't need to send
>> anything. If the final version differs from the current version,
>> submitters should send an email to
>> including:
>> * a revised submission package (including updated specs and reference
>> implementation); either as an attachment or as a URL
>> * a description of the tweak proposed and some rationale for this tweak
>> The panel will examine the proposed tweak and will then respond
>> whether or not the final version of the algorithm is accepted.
>> There's no formal definition of an acceptable tweak, but we plan to
>> accept any change that does not change fundamentally the algorithm.
>> For example, the tweak may consist in replacing BLAKE2 by SHA-512 as a
>> core primitive; in replacing a XOR by an ADD in some internal
>> algorithm; in changing the number of rounds of some function from 10
>> to 12; etc.
>> We also encourage submitters to polish the submission document and the
>> reference implementation of their algorithm. The clearer and the more
>> convincing, the easier it will be for the panel to understand the
>> merits of the algorithm and to assess it fairly against other
>> submissions.
> After the tweaks deadline, what (if any) changes would still be allowed?
> Further polishing of the specification document and the reference
> implementation, without a change of what hashes are computed for any of
> the valid inputs?
> Removal of optional features (extra modes of operation that are not
> exposed via the PHS() API)?
> Addition of optional features (ditto)?
> Changes to optional features (ditto), possibly changing what hashes are
> computed for some non-PHS() inputs/settings (thus, not affecting the PHC
> subset of the test vectors, but affecting some others)?
> Updates of existing optimized implementations (previously included in
> the submission package along with the reference implementation)?
> Addition of extra implementations?  Or should they stay outside of PHC,
> and if so would they be referenced from the PHC website or wiki at all?
> Alexander

Powered by blists - more mailing lists