phc-discussions - Re: [PHC] Competition process

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: <CALW8-7JjXVefH2echhOxhm-WpoXLFBkCskc=U3M7PKo+L6BD0Q@mail.gmail.com>
Date: Tue, 14 Apr 2015 16:13:30 +0200
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Competition process

Adding both things to Argon2 would not be a problem. Actually, we
already considered replacing our Blake2b round with BlaMKa (or any
other modification that employs a low-latency high-throughput
instruction). The S-boxes we did not consider yet.

On Tue, Apr 14, 2015 at 3:32 PM, Solar Designer <solar@...nwall.com> wrote:
> On Tue, Apr 14, 2015 at 10:31:08AM +0000, Peter Gutmann wrote:
>> Dmitry Khovratovich <khovratovich@...il.com> 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.
>
> Agreed.
>
> Alexander



-- 
Best regards,
Dmitry Khovratovich