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

On Mon, Mar 30, 2015 at 01:52:36PM +0200, Milan Broz wrote:
> On 03/30/2015 01:24 PM, Solar Designer wrote:
> > 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?

That paper describes the KDF column as indicating whether the scheme is
"Usable as a Key-Derivation Function (requires outputs to be
pseudorandom)".  I have no idea how the authors determined whether this
is the case or not for the various schemes, so yes - now I'd like a
clarification too.  Maybe this is about use of known strong crypto at
least on the outer layer?

It is clear that the author of POMELO v2 intended it to be used, among
other things, as a KDF.  Otherwise why optimize it for gigabyte sizes?

It is true that schemes without known strong crypto at least on the
outer layer provide less confidence, at least initially.

For practical purposes, the point is moot, and there's an easy fix of
e.g. passing the KDF output through SHA-256 or -512 if you're doing
weird things such as split the derived key in half or input it to a poor
cipher where the key's bit pattern somehow would matter.  Indeed, a
decent KDF would support such moderately weird uses directly, so needing
an extra step for peace of mind in those cases is a drawback.

There are other concerns with schemes not based on known strong crypto
primitives, but those concerns apply for password hashing use at least
as much.

Alexander