What Is Key Derivation? Password KDFs, HKDF, and Salts Explained

Key takeaways

• Key derivation produces key material from an input secret and defined parameters.
• Password-based functions make offline guessing more expensive but cannot create password entropy.
• HKDF derives keys from suitable secret material and is not a substitute for password hashing.
• Salts and context labels have different roles, and neither normally needs to be secret.

Key derivation is the process of producing cryptographic key material from an input secret using a key derivation function, or KDF. The input might be a password, a master key, or a shared secret established by a cryptographic protocol.

Those inputs are not interchangeable. A human password may be guessed from a short list. A securely generated random key has a very different distribution. Choosing a KDF starts with understanding that difference.

Imagine a document application that verifies account passwords and encrypts private files. Both features involve secrets, but storing a login verifier and deriving an encryption key are separate jobs.

Password Verification Does Not Require Decryption

For ordinary password login, the application needs to establish whether the submitted password matches the registered one. It does not need to retrieve the original password.

A password hashing library generates a salt, applies an appropriate password hashing function, and stores a verifier with the parameters needed for later verification.

When the user logs in, the library checks the submitted password against that record. The application should use the library’s verification operation rather than inventing its own comparison procedure.

Encrypting stored passwords would instead create a recoverable collection of credentials. That adds a decryption secret whose compromise can expose them all.

Why a Single SHA-256 Hash Is Insufficient

If an attacker steals the verifier database, they can try candidate passwords on their own hardware. Login rate limits no longer constrain those offline guesses.

A fast hash makes each attempt cheap. Adding a salt prevents some reuse of work, but a single salted SHA-256 calculation still remains fast.

Password-focused functions deliberately increase the resource cost per guess. Argon2 supports configurable memory, time, and parallelism parameters. Requiring memory as well as computation makes large-scale parallel guessing more costly.

That does not make a predictable password unguessable. The attacker can still try likely candidates first, which is why password entropy and storage protection address different parts of the problem.

What a Salt Does

A password salt is a random value generated for a password record and stored alongside it.

If two users choose the same password, distinct salts produce different verifier values. An attacker cannot simply use one precomputed result to match every account using that password.

The salt is not a second password. Keeping it secret is not its purpose, and losing it can prevent legitimate verification or key reconstruction.

A pepper is different: it is an additional secret kept separately from the password database. It can help in a database-only compromise, but introduces secret storage and rotation requirements.

Password KDFs and HKDF Solve Different Problems

The document application might also possess a securely generated master secret. It may need separate keys for distinct purposes rather than reusing that secret directly everywhere.

HKDF uses an extract-and-expand construction to derive output key material. Its context input, called info, can distinguish uses such as different protocol roles or application purposes.

HKDF is designed to be efficient. It does not supply the deliberate password-guessing cost of a password KDF. Feeding a weak password into HKDF does not turn it into a strong source secret.

Function or family	Typical role	Important distinction
Argon2id	Password hashing and password-based derivation	Configurable memory and computation costs
scrypt	Password-based derivation	Memory-hard construction
PBKDF2	Password-based derivation	Iteration-based cost
HKDF	Derivation from suitable secret key material	Context separation, not password stretching
bcrypt	Password verification, especially existing systems	Not a general replacement for arbitrary key derivation

The function must fit the protocol or storage design, not simply produce the desired number of bytes.

Deriving a File Encryption Key

For a passphrase-protected file, a password KDF can derive a key that an authenticated encryption scheme uses to protect the contents.

The application must retain the salt, KDF identifier, and parameters so the key can be derived again. Its file format also needs the encryption metadata required by the chosen scheme.

A salt and an encryption nonce are not interchangeable. Each has requirements defined by its algorithm. A KDF does not remove the need to use the encryption scheme correctly.

Changing the passphrase may require re-encrypting data or rewrapping a separate data key, depending on the design. Losing the necessary secret without a recovery mechanism can make the contents unrecoverable.

Cost Settings Need an Upgrade Plan

OWASP’s password storage guidance recommends Argon2id for new password storage where available and describes alternatives for deployment constraints.

Choose settings using current guidance and measurements on representative hardware. The service must handle legitimate concurrent logins without making resource exhaustion easy.

Store algorithm and cost information with each verifier. After a successful login, a library can identify an outdated record and replace it using the submitted password and current settings. Inactive accounts need a separate migration or reset policy.

Use the Library’s Supported Construction

Do not build a password scheme by concatenating secrets and repeatedly hashing them. Use maintained implementations and formats that specify salt generation, parameter encoding, verification, and upgrades.

For the document application, review password verification and file encryption separately. Then document which secret each function consumes, which parameters must be retained, and how recovery or rotation works.

Derivation provides a defined way to obtain keys. The surrounding design still determines whether those keys are used safely.

A longer derived key does not make the secret it came from harder to guess.