phc-discussions - Re: [PHC] RE: Deriving multiple keys (was RE: Mechanical tests)

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: <CAOLP8p7t_LkL7kqO3ubk6uW1xVeGHDR7UFqFeEjWF_eHssjqNQ@mail.gmail.com>
Date: Tue, 8 Apr 2014 18:55:58 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] RE: Deriving multiple keys (was RE: Mechanical tests)

On Tue, Apr 8, 2014 at 6:24 PM, Greg Zaverucha <gregz@...rosoft.com> wrote:
> After catching up on the list traffic I see this was already discussed earlier. Apologies
>
> I second Peter Gutmann's email from Sunday -- we need the winner to be a KDF, not something weaker.
>
> Greg

I agree that the winner(s) should be useable as a KDF, simply because
it likely will be used in that way regardless of the PHC
recommendations.  Any detectable non-randomness in the output should
be discouraged.  However, several entries (including mine) have
maximum output lengths no higher than the cryptographic primitive
used.  These could be used by running them multiple times, but they
wont replace the functionality of PBKDF2 or HKDF directly.  Other
entries appear to specifically compete against PBKDF2 and HKDF, rather
than performing memory-hard password scrambling, and those obviously
do need to be full-fledged KDFs.

Bill