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.1503311149270.7010@debian>
Date: Tue, 31 Mar 2015 12:10:06 +0200 (CEST)
From: Stefan.Lucks@...-weimar.de
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

Dear Honjun,

> Anyway, I will provide more analysis of POMELO in the updated report.  

I am looking forward to reading the updated report. It is a pity that you 
did not already provide this analysis!

> BTW, I think that it is not necessary to use strong crypto primitive 
> (such as strong hash function) in the design of password  hashing 
> scheme, especially if we want to process large amount of memory in a 
> fast way.   Eventually it turns out that a number of second round 
> candidates need to cut the round number significantly.   I feel that it 
> is no longer true that those PHC candidates are based on strong crypto 
> primitives, although they are still very strong.    

Having spent a significant amount of my scientific career with 
cryptanalysing primitives, I feel the urge to comment on this. There are 
two extreme choices to design a password hashing function (or anything 
else with required cryptographic strength):

(1) A construction based on an underlying strong primitive, with a formal 
reduction that the password hash function is secure if the primitive is 
secure.

(2) A novel primitive of its own right.

If the underlying primitive is already well-studied, (1) greatly 
simplifies cryptanalysis -- and makes it much less likely that any 
unexpected weaknesses are eventually discovered. Choice (2) is more 
difficult, but also more interesting and hopeful for the cryptanalysts.

There is also a middle ground:

(1.5) A password hash function based on the round function of an 
underlying strong primitive.

In this case, some of the cryptanalysis of the underlying primitive is not 
applicable any more, but some still is. And, while there is no immediate 
relationship between breaking the new construction and breaking the 
underlying primitive, an attack on the new construction could well 
undermine the trust into the underlying primitve.

Finally, a benefit of (1) and, to a lesser extent, (1.5) is that a user 
not willing to trust the proposed primitive can apply the same 
construction based on a different primitve. With (2), one can either use 
the primitive given, or not.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ