phc-discussions - Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

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]

Date: Tue, 31 Mar 2015 02:08:34 +0800
From: Hongjun Wu <wuhongjun@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

Dear Alexander and Milan,

Thank you, Alexander.  And thanks Milan for testing it.

1)  The speed of POMELO v2 is around 1Giga Byte per second on the Haswell
i7-4770K processor (for t_cost = 0, running at the turbo boost speed of 3.9
GHz, gcc compiler, and AVX2 instructions, as illustrated in the report.)

2)  POMELO can be used directly as KDF.
     The output of POMELO v2 is up to 256 bytes, and the output can be used
directly as the key.

3)  A strong hash function is not needed for POMELO.
     I believe that POMELO  is much stronger than any existing hash
function for the KDF/PH applications.  (For performance reason, a strong
hash function has to be sufficiently fast and small.  So even in a very
strong hash function, not many operations can be used for processing a
message block.)
     In the POMELO report, I did not talk much about POMELO against
preimage and collision attack. I can explain more in the updated report.
     When I was designing POMELO v2,  only the memory hardening security
worth my analysis.   The preimage and collision security are trivial.
Simply speaking, the state size of POMELO is too large comparing to a hash
function, and the operations used in a cryptographic hash function
(compression function) is much less than that used in POMELO.
     Some example: considering SHA-512, there are only 64+64 = 128 simple
steps to compress a 128-byte message (if we consider message expansion as
64 steps); while in POMELO v2, there are about 3*256 = 768 steps when
m_cost = 0, t_cost = 0.     In POMELO v2, in order to prevent password
hashing being too fast, it is required that m_cost + t_cost >= 5.  It means
that POMELO v2 consists of at least 32*256+512 = 8704 steps, far more than
that in a compression function of SHA-512.

Best Regards,
hongjun


On Mon, Mar 30, 2015 at 7:52 PM, Milan Broz <gmazyland@...il.com> wrote:

> On 03/30/2015 01:24 PM, Solar Designer wrote:
> > Milan,
> >
> > On Tue, Mar 24, 2015 at 11:50:44PM +0100, Milan Broz wrote:
> >> The updated test report (draft) is here
> >>
> >>   https://github.com/mbroz/PHCtest/blob/master/output/phc_round2.pdf
> >
> > This really needs the cross-chart we discussed - memory usage vs. real
> > time with increasing m_cost and fixed lowest supported t_cost.  From
> > your charts, it was - and still is - not apparent to me that (or
> > whether?) POMELO v2 performs so well (as the author claims) at large
> > memory settings.
>
> Yes, I'll plan to look into this soon.
>
> > And you did not include it in Table 4 ("Ability to
> > cover real use-case limits"), I guess because it was unclear even to you
> > that it's competitive for your use case.
>
> It is not there because I did not find any mention that POMELO can be used
> directly as a KDF in the paper (and the use case is for KDF).
> The garbage-collector attack paper http://eprint.iacr.org/2014/881 also
> mentions that it is not KDF in Table 4.
>
> Could authors clarify that?
>
> Milan
>

Content of type "text/html" skipped