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 18:52:31 -0500
From: Bill Cox <>
Subject: Re: [PHC] Are password trailing 0's a problem?

On Fri, Mar 7, 2014 at 6:30 PM, Andy Lutomirski <> wrote:
> On Fri, Mar 7, 2014 at 3:22 PM, Solar Designer <> wrote:
>> On Fri, Mar 07, 2014 at 05:21:06PM -0500, Bill Cox wrote:
>>> On Fri, Mar 7, 2014 at 11:49 AM, CodesInChaos <> wrote:
>>> > 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.
>> There are 95 printable 7-bit ASCII characters, not 70.  The attached
>> trivial program may do the trick in a couple of weeks on a fast server.
>> I've already found such "collisions" for 8-bit printable ASCII, and made
>> sure they do indeed work for scrypt as a whole as well (confirmed).
> It seems odd to me that PBKDF2 is being used in any PHC proposals.
> AAUI PBKDB2 was intended as a password hashing algorithm, and it's not
> very good.  The modern PHC candidates really want to use at as a
> function that maps arbitrary-length strings to arbitrary-length
> strings and that has "some of" the properties of a PRF, where "some
> of" is possibly not very well thought through.
> Why not use a simple, modern primitive for this?  To me, the obvious
> candidate is Keccak.  It's immune to generic attacks like this, which
> was half the point of developing it in the first place.  ISTM that it
> would be embarrassing for the PHC winner to have less resistance to
> generic attacks than a hash function should provide.
> --Andy

A sponge does seem pretty obvious for the purpose.  I'm using Blake2
which is faster, and HKDF_Extract and HKDF_Expand effectively turns it
into a sponge.  If I'm not mistaken, Blake2 also initializes quite a
bit faster, which is useful in my application where I hash 32 bytes
between every block hash.  I still feel wiggy about passing a password
directly to a cryto-strength hash function which may do enough
processing to enable an attacker to guess the length, though without a
scope probe on power rails or something similarly invasive, I don't
see how.


Powered by blists - more mailing lists