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: Tue, 17 Mar 2015 19:07:21 +0100
From: Milan Broz <>
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 [] 
> Sent: Tuesday, March 17, 2015 06:09
> To:
> Subject: [PHC] pre-hashed passwords?
> (After reading this nice post about passwords including null bytes:
> 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.)


Powered by blists - more mailing lists