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: <532EF2EB.8070502@bindshell.nl>
Date: Sun, 23 Mar 2014 07:42:51 -0700
From: Jeremi Gosney <epixoip@...dshell.nl>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Can I have two entries?

On 3/23/2014 7:37 AM, Solar Designer wrote:
> On Sun, Mar 23, 2014 at 07:24:25AM -0700, Jeremi Gosney wrote:
>> On 3/23/2014 7:13 AM, Solar Designer wrote:
>>> escrypt is just not ready for PHC yet given the full set of
>>> requirements I currently have for it (are post-submission let's say
>>> "major tweaks" OK?)
>> I believe we had previously discussed and agreed upon a period after the
>> initial review where submissions could be tweaked. I see no reason why
>> major tweaks within reason would be a problem. If your major tweaks
>> result in a dramatically different algorithm, then I think that would be
>> a problem :) But reasonable and organic enhancements should be fine as
>> long as the overall shape of the algorithm does not change.
> Yes, that's my understanding too, but it remains undefined how
> significant those "reasonable and organic enhancements" can be.

I'm not sure there is any way to define it concretely. I think it's
something that will largely be at the discretion of the panel, if based
on nothing more than gut reaction. If the majority feels that a change
is too dramatic, we can simply reject the modification.


> In the case of escrypt, it might be that its underlying structure would
> stay mostly the same, but the feature set might double.  I've been
> postponing work on all those bells and whistles like hash upgrades
> (despite of having suggested hash upgrades myself), focusing on
> escrypt's core first.  So now I have to choose between finalizing and
> properly documenting only the core (hopefully a complete submission but
> with only a subset of intended functionality) vs. adding the bells and
> whistles (but then the core will need tweaks later, and the
> documentation will be incomplete) vs. continuing the work at its natural
> pace and not submitting to PHC.

Just submit what you have, and continue to work on it. We'll work out
the details later :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ