5

What are some sample use-cases the NIST is supporting in this policy / whitepaper regarding PBKDF2?

This Recommendation specifies a family of password-based key derivation functions (PBKDFs) for deriving cryptographic keys from passwords or passphrases for the protection of electronically-stored data or for the protection of data protection keys.

I would have a better chance at understanding this paragraph if I knew what is implicitly excluded from that list of targeted applications.

Concrete examples of what is in scope and out of scope would be immensely helpful.

Improve this question

1 Answer 1

Reset to default
2

A Key Derivation Function turns some secret data into more secret data, and is used to make keys of appropriate size from other keys which do not have the appropriate size. An example of KDF is the one called "PRF" within SSL/TLS: it is used to convert whatever shared key was built between client and server (using RSA encryption or Diffie-Hellman) into the symmetric keys which will be used thereafter for symmetric encryption and integrity check in the established connection.

A Password-Based KDF (hence the name "PBKDF") is a KDF where the source material is a "password", i.e. a piece of data which is retained in the brain of a human being, and (usually) typed on a keyboard by the brain owner. This is not the case of SSL. A Password-Based KDF is used whenever you want to perform some data encryption "locked" by a password. For instance, when you "encrypt" a file with a password (e.g. the "password protection" in Word, or a password-protected Zip archive, or a PGP keyring or SSH private key stored in a file with "passphrase protection"), you can be sure that a Password-Based KDF was involved.

The job of a Password-Based KDF is to:

  1. accept as input a sequence of characters (of semi-arbitrary length), and output a sequence of bits of appropriate length for the intended cryptographic algorithm (e.g. 128 bits for AES encryption);
  2. "protect" the password against dictionary attacks by being appropriately slow and expensive (an attacker could try to guess the password by trying out potential passwords; we want each trial to be heavy and expensive for him), and by using a salt (so that attacking two encrypted files is twice as expensive as attacking one).

PBKDF2 ensures the second property through a configurable "number of iterations" and a salt (both parameters are typically stored in a public header for the encrypted file).

A devious but common usage of PBKDF2 is to hash passwords. This is about using the PBKDF2 output as a password verification token; a password will be accepted if the derivation through PBKDF2 will yield the same value. PBKDF2 was not initially designed for that, but still does an acceptable job of it, although bcrypt is arguably better (see this answer).

Improve this answer
2
  • Does that mean the NIST is OK'ing the use of PBKDF2 for password encryption with that whitepaper? (AKA the devious usages?)
    – makerofthings7
    Commented Sep 29, 2011 at 14:23
  • Yes, they do. They do not state that PBKDF2 is better than anything else, only that they consider PBKDF2 to be "good enough" for the purpose of hashing passwords.
    – Thomas Pornin
    Commented Sep 29, 2011 at 14:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .