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 14:51:57 -0800
From: "Dennis E. Hamilton" <>
To: <>
Subject: RE: [PHC] Are password trailing 0's a problem?


I missed that the first time.  

CodesInChaos is sort of saying that HMAC-SHA1 is not very collision resistant.  

Of course, all that happened was computation of SHA1 on 65-byte printable inputs until the result is a 20-byte output that has only the codes for printable ASCII characters.  These two would have the same HMAC result when used as a key.

I don't think that has any impact on PBKDF2 as a password-based key derivation, where collisions are not so much of a problem so long as finding any key, whether or not the one used originally, is seriously difficult.  That is, it's still a long way from demonstrating collisions to being able to find a particular one.

It does make pre-hashing an attractive precaution though.

 - Dennis

-----Original Message-----
From: CodesInChaos [] 
Sent: Friday, March 7, 2014 08:50
Subject: Re: [PHC] Are password trailing 0's a problem?

[ ... ]
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:

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.

Powered by blists - more mailing lists