phc-discussions - Re: [PHC] pre-hashed passwords?

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: <55086D59.7020706@gmail.com>
Date: Tue, 17 Mar 2015 19:07:21 +0100
From: Milan Broz <gmazyland@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] pre-hashed passwords?

On 03/17/2015 06:22 PM, Dennis E. Hamilton wrote:
>  -- in reply below to --
> From: Jean-Philippe Aumasson [mailto:jeanphilippe.aumasson@...il.com] 
> Sent: Tuesday, March 17, 2015 06:09
> To: discussions@...sword-hashing.net
> Subject: [PHC] pre-hashed passwords?
> 
> (After reading this nice post about passwords including null bytes:
> http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html)
> 
> Has anyone already seen password hashes "pre-hashing" a password, to
> handle length limitations? Things like
> 
> password_hash(hash('sha256', $password, true), PASSWORD_DEFAULT)
> 
> password_hash(hash_hmac('sha256', $password, $key, true), PASSWORD_DEFAULT)
> 
> <orcmid>  
>    PBKDF2 does that when the password length exceeds a block-size 
>    limitation.

Yes, it is problem how HMAC works there.

Not sure if it is what you meant, but maybe interesting use case:

Cryptsetup/LUKS derives unlocking key (key which decrypts the volume encryption key)
using PBKDF2 even when used with "keyfiles".
Keyfiles can be quite big and are always passed through PBKDF2.

Apparently it exceeds internal block size, so the internal PBKDF2/HMAC
applies hashing.

Unfortunately, cryptsetup also supports several cryptographic backends
and not all provides native PBKDF2, so we have to use internal PBKDF2
implementation in this case.

And sometimes it doesn't provide HMAC_reset function neither
(IOW reset of internal HMAC state without rehasing the whole output,
in gcrypt it would be is gcry_md_reset, in openssl EVP_DigestInit etc).

This has a nasty side effect that when you need to calculate HMAC
in every PBKDF2 iteration, the whole input is hashed again and again and
this takes a lot of wasted computing time.

So pre-hashing PBKDF2 input is very effective workaround in this case.

Actually, processing of unlimited input in PHC functions is very important
attribute for the use in LUKS FDE in future.

If pre-hashing is used internally, it should not have the collisions problems
like PBKDF2 has. (Yescrypt solves this problem nicely because scrypt
uses PBKDF2 on input as well.)

Milan