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]

Date: Tue, 8 Apr 2014 23:27:58 +0000
From: Greg Zaverucha <gregz@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] RE: Deriving multiple keys (was RE: Mechanical tests)

After looking at the call for submissions, the ability to generate arbitrary length outputs was optional.   It seems like an easy enough feature to add (e.g., just calling a conventional KDF at the end of the "password scrambling" to produce the final key), but designers should specify how to do it with their algorithm.  If the winner didn't specify a way to do it, users would likely invent their own incompatible ways (and maybe even insecure).  

Greg

-----Original Message-----
From: Bill Cox [mailto:waywardgeek@...il.com] 
Sent: Tuesday, April 8, 2014 3:56 PM
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