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-next>] [day] [month] [year] [list]
Date: Wed, 26 Feb 2014 00:31:21 -0500
From: Bill Cox <>
Subject: Should we care about "parameter influence" attacks against PBKDF2?

This is probably a case of my being ignorant because I'm new to
password hashing.  I'd appreciate feedback.  I learn quickly with

I read this paper because there's a link to it from the PHC FAQ:

Design and Analysis of Password-Based Key Derivation Functions

There's some very cool stuff there, and the attack on PBKDF2 based on
the ability to have the user re-enter his password while an attacker
chooses a number of hash rounds is brilliant, and belongs in a paper,
but should we take action to defend against this attack, or simply
enjoy it's novelty?

In particular, this attack assumes the attacker can choose input
parameters other than the password, and then have the user use those
parameters and reenter the password.  The hashing then takes place
where the attacker can see the resulting hash value, but not the
password.  I have difficulty finding the motivation to upgrade my KDF
to defend against this scenario.  Is it even remotely possible?

In particular, if an attacker can chose inputs other than the
password, why not just make the salt 0 so he can do a dictionary
attack?  How does hashing all the input parameters defend against
attacker chosen salt?  I read code where the salt length is hashed
in... am I being daft (which I often am), or is that as useless as it
seems at face value?

Which is more likely of these two possibilities? 1) the KDF designer
messed up and has a way to attack his algorithm because he didn't hash
in all the input parameters, and 2) a random implementer messed up the
hashing of all the input parameters, creating a weakness.

Can I just ignore this case?


Powered by blists - more mailing lists