Clarification needed for NIST's whitepaper "Recommendation for Password-Based Key Derivation"

Question

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.

Answer 1

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).