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  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: Fri, 7 Mar 2014 17:21:06 -0500
From: Bill Cox <>
Subject: Re: [PHC] Are password trailing 0's a problem?

On Fri, Mar 7, 2014 at 11:49 AM, CodesInChaos <> wrote:
> This results from PBKDF2 using the password as HMAC key instead of message.
> HMAC seems to be designed with a fixed length uniformly random key
> (i.e. it aims to be a PRF),
> so I consider using the password as key instead of message abuse.

I see.  That may help explain why HKDF uses the password as the message.

> HMAC is a bit weird with variable size keys:
> * If the key is shorter than the block size, pad it with zero bytes
> * If the key is longer than the block size, hash it
> This is generally not a problem for the usual thread model of HMAC
> (assumes uniformly random keys with fixed size) and PBKDF2 (password
> hashing, only first pre-images matter).
> But it means that there are trivial collisions and even second
> pre-images (add a 0 byte at the end, if the original key was shorter
> than the block size, this won't have any effect).
> As an example with nice printable characters in both passwords:
> `plnlrtfpijpuhqylxbgqiiyipieyxvfsavzgxbbcfusqkozwpngsyejqlmjsytrmd`
> and `eBkXQTfuBqp'cTcar&g*` have the same PBKDF2-HMAC-SHA1 hash (no
> matter the salt or the number of iterations).
> I found those with a CPU and unoptimized code. One of our GPU hashing
> friends could easily find a similar pair for PBKDF2-HMAC-SHA-256.

Sweet.  I assume the only difficulty is finding a printable character
hash, which is something like 70 out of 256 values, so the printable
hashes for HMAC-SHA256 would be 1 in (70/256)^32.  We'd have to search
about 1e18 to find one, so a billion billion... definitely time for a
GPU farm.


Powered by blists - more mailing lists