Key derivation function

A key derivation function (KDF) is a cryptographic algorithm that derives one or more sets of keying material from an existing secret, such as a shared key, a key-agreement result or a password, together with context information and other parameters. KDFs let a protocol turn one secret into keys of the required length and assign separate keys to separate purposes.

The term covers two related but distinct classes. A key-based KDF starts from input that already has substantial cryptographic strength. A password-based KDF starts from a human-selected password or passphrase and deliberately raises the cost of testing guesses. Confusing the two can produce insecure designs: a fast general KDF does not make a weak password resistant to offline guessing.

Key-based derivation

Protocols often obtain an initial secret through a key-agreement operation and then need different keys for encryption, message authentication or distinct directions of a connection. A KDF can combine the secret with labels and context—such as protocol identifiers, party identities or transcript data—so that outputs for different purposes are separated.

NIST SP 800-108 specifies counter, feedback and double-pipeline constructions based on pseudorandom functions including HMAC, CMAC and KMAC. The exact construction and its inputs are part of a protocol specification; merely hashing a secret without domain separation may not provide the required properties.

Extract and expand

HKDF is an HMAC-based KDF standardized in RFC 5869. It follows an extract-then-expand design. The extract stage converts potentially non-uniform input keying material into a fixed-length pseudorandom key. The expand stage derives one or more outputs while binding optional context information.

HKDF is intended for cryptographic keying material such as a Diffie–Hellman result. It is deliberately efficient and is not a replacement for a password hashing scheme when the input can be guessed from a small dictionary.

Password-based derivation

A password-based KDF combines a password with a salt and cost parameters. The salt is normally stored with the result and need not be secret. Its purpose is to make identical passwords produce different outputs and to prevent one precomputed table from being reused across many records. The work factor makes every guess more expensive for both the legitimate system and an attacker.

PBKDF2 applies a pseudorandom function repeatedly and is specified by PKCS #5 and NIST guidance. Its main adjustable cost is an iteration count. That parameter must be selected for the application and hardware and should be increased over time where compatibility permits; there is no permanent iteration count that is appropriate for every system.

Modern password hashing schemes can also impose a configurable memory cost. Memory-hard functions aim to make large-scale guessing expensive not only in processor operations but also in memory and bandwidth. scrypt, Argon2 and Lyra2 are examples of designs in this family. RFC 9106 specifies Argon2 and recommends the hybrid Argon2id variant for general password hashing, with profiles chosen according to available memory and latency.

Uses

KDFs are used to:

• derive traffic keys and initialization material after a key exchange;
• create separate encryption and authentication keys from one master secret;
• bind keys to a protocol, session, identity or purpose;
• derive a storage-encryption key from a passphrase;
• store a verifier derived from a password rather than the password itself; and
• produce a key of an exact length required by another cryptographic primitive.

A password verifier and an encryption key can both be outputs of password-based derivation, but their surrounding threat models differ. Password verification must limit online attempts and protect the verifier database; storage encryption must also consider how the derived key is erased, retained and recovered.

Security considerations

The security of a KDF depends on the strength of its input, the construction, parameter choices and context binding. A KDF cannot create entropy that is absent from a guessable password. Salts prevent cross-record precomputation but do not need to be guessed, and they do not slow a targeted attack by themselves.

For password-based use, cost parameters should be calibrated on the actual deployment so legitimate use remains acceptable while guesses are expensive. Implementations must also bound attacker-controlled parameters to avoid denial of service, compare password verifiers without leaking useful timing information, and migrate old parameter sets after successful authentication. A secret server-side value, sometimes called a pepper, can add a separate protection layer but is not a substitute for a unique salt or a suitable password hashing function.

For key-based use, applications should follow the KDF defined by their protocol rather than inventing a new composition. Reusing one derived key for unrelated algorithms or omitting the protocol context can defeat separation between uses.

Standards and historical development

Early Unix password storage was an important predecessor of modern password-based KDFs. Robert Morris and Ken Thompson's 1979 account described a crypt design that used the first eight password characters as a key, applied a modified DES computation 25 times and selected one of 4,096 variants with a 12-bit salt. The salt frustrated reuse of one precomputed dictionary across all accounts, while the repeated computation increased the cost of each guess on contemporary hardware. Fixed limits and increasing computing power eventually made this scheme unsuitable for modern password protection.

Later password hashes introduced adjustable cost parameters and stronger primitives. Bcrypt added an adaptable work factor in the 1990s; scrypt added a configurable memory cost; and the Password Hashing Competition selected Argon2 while giving special recognition to Catena, Lyra2, Makwa and yescrypt. These functions are not interchangeable solely because each can process a password: applications must follow the selected function's encoding, parameter and migration rules.

NIST SP 800-132 specifies PBKDF2-based derivation for protecting stored data and carries a notice that NIST plans to revise the publication. Current NIST digital-identity guidance requires salted password hashing with a suitable scheme and recommends a memory-hard function. These requirements apply to password verifiers; they should not be generalized into a claim that every cryptographic KDF must be slow or memory-hard.