Skip to main content
Commerce Security Authority
Category: Cryptography Fundamentals

Key Derivation Function

Also known as: KDF, key-derivation function
Simply put

A key derivation function is a cryptographic algorithm that produces one or more secret keys from an input secret value, such as a master key, a shared secret, or a password. It is used to turn a single starting value into usable keying material for cryptographic operations while helping protect the underlying secret. Different KDFs are designed for different inputs and purposes, so the appropriate choice depends on the use case.

Formal definition

A KDF derives secret keying material from a source of initial keying material (for example, a shared secret established during key agreement, an existing key, or a low-entropy password) together with additional context or salt information. NIST defines it as a function used to derive secret keying material from a shared secret or key and other information. Constructions vary by purpose: HKDF (RFC 5869) is an HMAC-based extract-and-expand KDF intended as a building block where the input already has sufficient entropy, whereas password-based KDFs are designed to add computational cost when deriving keys from low-entropy secrets. Selection, parameters, and inputs (such as salts and context binding) should follow current published guidance and the specific standard governing the deployment; implementers should confirm details against the applicable specification rather than assuming a single KDF fits all scenarios.

Why it matters

Cryptographic systems rarely use a single master secret directly for every operation. Reusing one key across many purposes, or deriving keys in an ad hoc way, can weaken the security guarantees of an otherwise sound design. A key derivation function provides a disciplined way to turn one input secret into distinct, purpose-bound keying material, which helps limit the impact if any single derived key is exposed and helps prevent unintended relationships between keys used for different functions.

The correct KDF depends on the nature of the input. When the input already has sufficient entropy, such as a shared secret established during key agreement, an extract-and-expand construction like HKDF (RFC 5869) is intended to produce well-distributed keying material as a building block within a larger protocol. When the input is a low-entropy secret such as a password, a password-based KDF is designed to add deliberate computational cost, which is intended to make brute-force guessing more expensive. Choosing a general-purpose KDF where a password-hardening function is required, or vice versa, can undermine the protection the system relies on.

Because parameters, salts, and context binding materially affect the outcome, KDF selection and configuration should follow current published guidance and the specific standard governing the deployment. A label alone does not guarantee an appropriate outcome; implementers should confirm details against the applicable specification rather than assuming a single KDF fits every scenario.

Who it's relevant to

Security engineers and cryptography implementers
Engineers building or integrating cryptographic protocols need to select a KDF appropriate to their input. They should distinguish extract-and-expand functions such as HKDF, intended for inputs that already have sufficient entropy, from password-based KDFs designed to add computational cost for low-entropy secrets, and should confirm parameters, salts, and context binding against the specification governing their deployment.
Application and platform developers handling secrets
Developers who derive keys from passwords or shared secrets rely on KDFs to produce usable keying material while helping protect the underlying secret. Using a general-purpose KDF where password hardening is required, or omitting salts and context binding, can weaken protection, so developers should follow current published guidance rather than assuming any single KDF fits all cases.
Compliance and standards reviewers
Reviewers assessing cryptographic implementations should verify that the chosen KDF and its parameters align with the specific standard governing the deployment. Because appropriate selection and configuration depend on the use case and current guidance, reviewers should check details against the applicable specification rather than treating the KDF label as sufficient evidence of correct use.

Inside KDF

Input Keying Material
The source secret or master key from which one or more derived keys are produced. Depending on the KDF, this may be a master key, a password or passphrase, or a shared secret established through a key agreement process.
Salt or Nonce
A non-secret, ideally unique value combined with the input keying material to help ensure that the same input does not always produce the same derived key and to reduce the effectiveness of precomputation attacks. Its role and requirements depend on the specific KDF construction.
Context or Info Parameter
Additional binding data, sometimes called label, context, or info, that ties a derived key to a particular purpose, session, or party. This helps produce distinct keys for distinct uses from the same input keying material.
Iteration or Work Factor
For password-based KDFs, a configurable cost parameter (such as iteration count, memory, or parallelism) intended to increase the computational effort required per guess. This is a property of certain KDF designs and not a universal feature of all KDFs.
Underlying Cryptographic Primitive
The building block a KDF relies on, such as a keyed hash (HMAC) or a block cipher. The KDF's security properties depend on the strength and correct use of this primitive.
Derived Key Output
The resulting key or keying material of a requested length, intended for use in encryption, authentication, or further key management. A KDF is intended to produce output that is computationally independent from other outputs derived under different parameters.

Common questions

Answers to the questions practitioners most commonly ask about KDF.

Is a Key Derivation Function the same as a general-purpose hash function?
No. While many KDFs are built on top of cryptographic hash functions or use them internally (for example via HMAC), a KDF is not simply a hash. A raw hash function is designed for speed and is intended to produce a fixed-length digest, whereas a KDF is intended to derive one or more cryptographic keys from an input such as a shared secret, master key, or password. Password-oriented KDFs are additionally designed to be deliberately slow or memory-hard to help resist brute-force attacks, which is the opposite goal of a fast general-purpose hash. Treating a bare hash as a KDF can weaken key material, so you should select a function purpose-built for key derivation.
Does using a KDF by itself satisfy encryption or key-management requirements?
No. A KDF is one component within a broader key-management process, not a substitute for it. It helps derive keys but does not on its own address key generation entropy, secure key storage, access controls, key rotation, or key destruction. Encryption of cardholder data and the surrounding key-management practices are governed by the applicable PCI DSS requirements, and related standards such as PCI PIN or PCI P2PE may apply to specific environments. Confirm the exact obligations against the current published standard, because requirement numbering and wording differ between versions, and treat the KDF as part of an overall design rather than a control that stands alone.
What inputs should a KDF receive to derive keys reliably?
A KDF typically takes an input keying material or secret (such as a shared secret, master key, or password), and, depending on the function, additional parameters such as a salt or nonce, context or label information to bind the derived key to a purpose, and an output length. For password-based derivation, a work factor such as an iteration count or memory parameter is also supplied. Providing a unique salt per derivation is intended to help ensure that identical inputs do not produce identical derived keys, which may reduce the effectiveness of precomputation attacks. The specific inputs and their handling depend on the chosen function and its documented specification.
How do you choose work-factor parameters for a password-based KDF?
Work-factor parameters such as iteration count, memory cost, and parallelism are intended to make derivation deliberately expensive so as to help slow brute-force attempts. Choosing them involves a trade-off: higher values may improve resistance to offline attacks but increase latency and resource use on your own systems, which can affect throughput and user experience. Parameters are generally tuned against your target hardware and acceptable processing time, and revisited over time as computing capacity changes. Exact recommended values depend on the source, algorithm, and period, so validate against current authoritative guidance for the specific function you deploy rather than assuming a fixed number.
How does key derivation relate to key rotation and versioning?
Deriving multiple keys from a master secret using distinct context or label inputs can support operational separation, but derivation does not by itself provide rotation. If a master input is compromised, keys derived from it may also be exposed, so rotation and versioning of the underlying key material remain necessary. Tracking which derivation parameters, salts, and context values produced a given key is important so that keys can be reproduced or retired in a controlled way. These practices sit within your overall key-management lifecycle, whose specific controls should be confirmed against the applicable current standard.
What should be tested or validated when implementing a KDF?
Validation generally includes confirming that the implementation matches the documented specification of the chosen function, that salts or nonces are unique and generated with adequate entropy where required, that derived keys are the expected length and are bound to their intended context, and that work-factor parameters are applied as configured. You would also verify that inputs and derived keys are handled securely in memory and are not inadvertently logged or persisted. Whether and how this must be formally validated depends on your environment and the relevant standard, so confirm the specific expectations against the current published requirements rather than assuming a fixed procedure.

Common misconceptions

A KDF is the same thing as encryption, so running data through a KDF protects that data like ciphertext.
A KDF derives keys from input keying material; it is not a data confidentiality mechanism and does not encrypt cardholder data. Encryption transforms data reversibly with a key, while a KDF produces keys. These serve different purposes, and the effect of any of them on PCI DSS scope depends on the overall implementation and validation, not on the label alone.
A general-purpose KDF and a fast hash function are interchangeable for turning passwords into keys.
Password-based KDFs are designed with a tunable work factor intended to slow down guessing, whereas an ordinary fast hash lacks that property. Using a plain fast hash where a password-based KDF is appropriate can weaken resistance to brute-force attempts. The correct choice depends on whether the input is a high-entropy secret or a low-entropy password.
Because a KDF handles key material, it can be used to store sensitive authentication data more safely after authorization.
Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization even when transformed. A KDF does not change that prohibition; it addresses key derivation, not the permissibility of retaining sensitive authentication data.

Best practices

Select a KDF suited to the input type, using a password-based KDF with an appropriate work factor for low-entropy secrets and a standards-based KDF for high-entropy keying material.
Use unique salts or nonces where the chosen KDF calls for them, and bind derived keys to their intended purpose using a distinct context or info parameter so that keys for different uses do not collide.
Rely on well-reviewed, published KDF constructions and vetted cryptographic libraries rather than custom or homegrown derivation logic.
Manage the input keying material and any derived keys under defined key-management controls, including secure generation, storage, rotation, and retirement.
Do not treat a KDF as a substitute for encryption, tokenization, truncation, masking, or hashing when protecting stored cardholder data, and confirm any scoping impact through proper validation against the current published standard.
Never use a KDF as a justification for retaining sensitive authentication data after authorization, and confirm control choices against the current published PCI DSS version rather than assuming fixed requirement numbers.