phc-discussions - Re: [PHC] Let's not degenerate when if the PRF is too narrow for desired output

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: <2FFD384A-A2EC-429D-A598-C5FF1BB1CF70@gmail.com>
Date: Wed, 17 Apr 2013 08:25:07 -0400
From: Matthew Green <matthewdgreen@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Cc: Jeffrey Goldberg <jeffrey@...dmark.org>,
 "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Let's not degenerate when if the PRF is too narrow for desired output

I think this statement could be relaxed a bit, but I also agree that overall computational cost should be dominated by the work factor specified as input to the function -- it should not depend strongly (i.e., linearly) on output length.

This would be a real issue in an authentication system where the defender was generating long 'hashes' but an attacker could save cycles by only computing a shorter prefix to test against.

By the way, this would seem to be an issue for scrypt as well, since it uses PBKDF2 for the final generation. 

We should discuss whether we want this to be a criteria for PHC. 

Matt

On Apr 17, 2013, at 5:26 AM, Simon Josefsson <simon@...efsson.org> wrote:

> Jeffrey Goldberg <jeffrey@...dmark.org> writes:
> 
>> This is mostly me whining. I just got bitten by the fact that PBKDF2
>> does weird stuff if you ask for more derived data than is natural for
>> the PRF you give it.
> 
> Perhaps this can be converted into a requirement for a nicer KDF: the
> cost to compute one bit of the output should be as high as computing the
> entire output?
> 
> /Simon