phc-discussions - Re: [PHC] PHC status report

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: <alpine.DEB.2.11.1502121804180.17286@debian>
Date: Thu, 12 Feb 2015 18:29:34 +0100 (CET)
From: Stefan.Lucks@...-weimar.de
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] PHC status report

On Thu, 12 Feb 2015, Donghoon Chang wrote:

Dear Donghoon,

this will be my last posting on the SHA-3 process, since it starts to 
become off topic for PHC. Having been on the submitters' side in SHA-3, I 
cannot see much difference between how the first round of SHA-3 and the 
first round of PHC has been handled. And I believe, the entire SHA-3 
process was handled quite well by the NIST. Of course, I may be biased 
because the Skein got into the 2nd round and even into the final. ;-)

> => From the view of the structural soundness of Keccak, the 
> invertibility of the Keccak permutation is not at issue, because the 
> sponge construction, which is the domain extension of Keccak, is proved 
> to be collision resistant, preimage resistant, second 
> preimage resistant, and indifferentiable in the single stage game in the 
> ideal permutation model.

Now *that* is very debatable! Some classes of hash functions had standard 
model proofs for their security (if the compression function is collision 
resistant, then so is the hash function), some had to rely on (some people 
would say, dream up) an idealized model. I understand why the NIST decided 
that way, but this is judgement, not scientific evidence. Though I respect 
the choices made by the NIST, but I would not agree with that specific 
one. (But yes, I am biased.)

> So, here, a main issue is that it is reasonable to assume that there is 
> no any non-trivial non-randomness property of the Keccak permutation.

Zero-sum distinguishers!

I understand well why these where not taken as a reason to kill Keccak, 
but claiming no non-trivial non-randomness property is plain wrong.

> => As you agree, we should not make any mistake once again.

I would always agree that one should not make any mistakes again. :-)

But I don't agree about the NIST having been mistaken in the SHA-3 
selection process you claim. I actually believe the people from NIST did a 
great job, and it is good to follow their lead!

> That's why now I request the PHC panel to take only good aspects of NIST 
> SHA-3 selection process, by writing a public report and by evaluating 
> each PHC candidate according to security and performance. 

This has been done. And the report actually gives more information to the 
submitters who's Password Hashing Function has been rejected, than the 
SHA-3 first-round report did to the rejected SHA-3 candidates.

The main difference is the amount of analysis available (cryptanalysis, 
but also implementations, benchmarks ect.) Unlike the NIST with SHA-3, the 
PHC committee had only that much information to base its decision on.

Stefan

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--