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

Powered by Openwall GNU/*/Linux Powered by OpenVZ