phc-discussions - Should we care about "parameter influence" attacks against PBKDF2?

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-next>] [day] [month] [year] [list]

Message-ID: <CAOLP8p7B1nDKo95uQj9CM9YxmKcA_Dh+xCk+=0tfMGCZGcp5+Q@mail.gmail.com>
Date: Wed, 26 Feb 2014 00:31:21 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
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
guidance.

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

Design and Analysis of Password-Based Key Derivation Functions
http://palms.ee.princeton.edu/PALMSopen/yao05design.pdf

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?

Bill