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  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: Tue, 14 Apr 2015 16:32:43 +0300
From: Solar Designer <>
Subject: Re: [PHC] Competition process

On Tue, Apr 14, 2015 at 10:31:08AM +0000, Peter Gutmann wrote:
> Dmitry Khovratovich <> writes:
> >2) The submissions evolve over the competition period significantly,
> >absorbing new ideas and constructions from the discussion, possibly even
> >merging with each other. The confidence in the winner(s) comes from the
> >consensus in the committee on certain features that are gradually integrated
> >in the final version.
> That's the approach I prefer (see my earlier thoughts about allowing a final
> round of updates for the top three, before a single best-of-breed is chosen).

I think we might want to specifically encourage collaborative work.

For example, it should be easy for Argon2 to adopt Lyra2's BlaMKa and
make this the standard mode (whereas in Lyra2 it's an option), but it
might be better for Argon2d to adopt yescrypt's pwxform (not for
Argon2i, because pwxform makes data-dependent S-box lookups).

Maybe Argon2i could use a revision of Blake2b with BlaMKa, and Argon2d
would have it preceded by pwxform (it still needs a round of Blake2b, or
modified Blake2b with BlaMKa, as well - to provide diffusion).

I think Argon2d's performance would remain good even with these changes.
Most of its invocations of Blake2b round would be replaced with pwxform,
with only one remaining (for up to 1024-bit parallelism, which is enough
on current and near future CPUs).

Needing to initialize pwxform S-boxes adds complexity, though.  So this
is probably not something to be done without the panel saying this is a
defense vs. complexity balance they like.

> Argon2 is such an obvious improvement, it seems odd to keep it out so that the
> decision has to be made on a previous-generation version.  Or, more
> worryingly, that the decision on Argon might be made on the assumption that
> what'll be adopted is actually Argon2, blurring the line over what's being
> decided on.



Powered by blists - more mailing lists