[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150130140711.GA17358@openwall.com>
Date: Fri, 30 Jan 2015 17:07:11 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC finalists tweaks (SUBMITTERS, please read carefully)
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 submissions@...sword-hashing.net
> 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