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
| ||
|
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
Powered by blists - more mailing lists