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]

Message-ID: <CAOLP8p7KUkUksTHEEo1ehHteHL7K2Vmxunn2NrwnJV8gdVhdDg@mail.gmail.com>
Date: Fri, 7 Mar 2014 17:21:06 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

On Fri, Mar 7, 2014 at 11:49 AM, CodesInChaos <codesinchaos@...il.com> 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.

Bill