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  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, 31 Mar 2015 12:41:17 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

Hi Hongjun,

On Tue, Mar 31, 2015 at 11:11:59AM +0800, Hongjun Wu wrote:
> First, I'd like to point out that the security of preimage/collision of
> Pomelo (and some PHC Second round candidates) is somehow similar to the
> security of the initialization of stream ciphers, rather than similar to
> the security of hash function in which there is no secret key.
> 
> When I was designing POMELO, the first priority is to ensure that the
> password cannot be recovered due to collision (it follows from my
> experience on the cryptanalysis and design of stream ciphers).  It is the
> reason that the first half operations of POMELO are strictly revertible so
> as to prevent collision, but to achieve diffusion.
> 
> Some confusion/diffusion idea of POMELO partly comes from my stream cipher
> HC (i.e., using expansion and table lookups).  Since its publication in
> 2004, HC remains as a very strong cipher.

Thank you for this additional detail.  It helps.  It's actually mostly
not me who you need to convince, but first the PHC panel as a whole and
then users of POMELO.  When deciding on the winners, the PHC panel will
consider not only whether the panel members themselves are convinced of
a PHC finalist's security, but also whether it'd be convincing to
prospective adopters of the scheme.

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

This will be very helpful.

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

Right.  The PHC panel understands this too, which is why e.g. POMELO
made it to finalists.

> 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.
> 
> Maybe we can now say that most of the second round candidates are no longer
> built on strong crypto primitives (such as strong hash functions or strong
> block ciphers) to achieve their security,  not just POMELO itself.

You're right, it's not just POMELO.

Alexander

Powered by blists - more mailing lists