phc-discussions - Re: [PHC] PHC finalists tweaks (SUBMITTERS, please read carefully)

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: <CAGiyFdeESE-5RH7L=0Zzkz27O=e9c4P0cMg6kNa+c5f04n4BYA@mail.gmail.com>
Date: Fri, 30 Jan 2015 15:19:26 +0100
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
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 <solar@...nwall.com> 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 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