phc-discussions - Re: [PHC] Are password trailing 0's a problem?

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: Fri, 7 Mar 2014 17:49:30 +0100
From: CodesInChaos <codesinchaos@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

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.

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.