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 18:52:31 -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 6:30 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Fri, Mar 7, 2014 at 3:22 PM, Solar Designer <solar@...nwall.com> wrote:
>> On Fri, Mar 07, 2014 at 05:21:06PM -0500, Bill Cox wrote:
>>> On Fri, Mar 7, 2014 at 11:49 AM, CodesInChaos <codesinchaos@...il.com> 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.

Bill