Key Derivation Functions: Security Algorithm Guide

1. Introduction and Core Concepts

Key Derivation Functions (KDFs) are fundamental cryptographic primitives that transform weak, low-entropy, or shared secret inputs into strong, uniformly distributed cryptographic keys suitable for encryption, authentication, and other security operations. Unlike simple hash functions, KDFs are deliberately designed to be computationally expensive, memory-intensive, or both, making brute-force and dictionary attacks prohibitively costly even when the original secret is a human-memorable password.

At its core, a key derivation function addresses a critical gap in applied cryptography: raw secrets are rarely suitable for direct use as keys. Passwords chosen by users typically contain only 20 to 40 bits of entropy, far below the 128 or 256 bits required for modern symmetric ciphers like AES-256. Similarly, the shared secret produced by a Diffie-Hellman key exchange is a large integer with algebraic structure and biases that make it unsuitable as a direct encryption key. A KDF solves this by extracting entropy, expanding it to the required length, and ensuring the output is indistinguishable from random.

The importance of KDFs cannot be overstated in modern security architecture. Every time you log into a web application, connect to a Wi-Fi network using WPA3, encrypt a file with a passphrase, or establish a TLS 1.3 session, a KDF is operating behind the scenes. Without properly configured KDFs, systems that store password hashes would be vulnerable to offline cracking with GPUs and ASICs, and key agreement protocols would leak information about derived keys. Understanding how KDFs work, when to use each variant, and how to configure them correctly is essential for any engineer building secure systems.

What Makes a KDF Different from a Hash Function?

A cryptographic hash function like SHA-256 is designed to be fast and efficient, processing gigabytes per second on modern hardware. This speed is precisely what makes it unsuitable for password-based key derivation. An attacker can try billions of password guesses per second using a fast hash. A KDF inverts this property: it intentionally introduces computational cost through iteration, memory hardness, or parallelism requirements. This asymmetry ensures that legitimate users incur a tolerable delay of 200-500 milliseconds during login, while attackers face costs that are millions of times higher when attempting large-scale cracking.

KDFs also provide domain separation, salt support, and output length flexibility. Salting ensures that identical passwords produce different derived keys, defeating rainbow table attacks. Configurable output length allows a single master secret to derive multiple independent subkeys for different purposes, such as separate encryption and authentication keys, without cryptographic linkage between them.

2. How It Works

Most key derivation functions operate in two conceptual phases: extraction and expansion. Extraction concentrates potentially diffuse entropy from the input secret into a short, uniformly random pseudorandom key (PRK). Expansion then stretches that PRK into an arbitrary amount of output key material using a pseudorandom function (PRF), typically HMAC-SHA256 or HMAC-SHA512. This extract-then-expand paradigm, formalized in HKDF (RFC 5869), provides strong security proofs and clean separation of concerns.

Password-based KDFs such as PBKDF2, bcrypt, scrypt, and Argon2 add additional defenses tailored to low-entropy inputs. PBKDF2 achieves this through iterated HMAC: it applies HMAC-SHA256 thousands or hundreds of thousands of times, chaining the output of each iteration as input to the next. The iteration count, often denoted as c, directly controls the computational cost. bcrypt builds on the Blowfish cipher's expensive key schedule, repeatedly encrypting a constant string with the password-derived key. scrypt and Argon2 go further by requiring large amounts of memory that must be accessed in a pseudorandom pattern, which neutralizes the advantage of highly parallel custom hardware.

Salting is a non-secret random value, typically 16 bytes or more, that is unique per derivation. The salt is concatenated with the password before hashing, ensuring that an attacker must attack each password hash individually rather than precomputing a table for all users. A pepper, sometimes confused with a salt, is a secret application-wide value stored separately from the database, often in an HSM, that adds defense-in-depth if the password database is compromised.

The Role of Memory Hardness

Memory hardness is the defining innovation of modern KDFs. While PBKDF2 and bcrypt are computationally hard, they require minimal memory, allowing attackers to implement them efficiently on GPUs that can run thousands of instances in parallel. scrypt was the first widely adopted memory-hard KDF, requiring the defender to allocate, for example, 16 MB of RAM per derivation. Argon2, the winner of the Password Hashing Competition in 2015, improves on this by providing tunable memory, time, and parallelism parameters, and by offering resistance to side-channel and tradeoff attacks. The memory requirement forces attackers to spend silicon area on RAM rather than on more cracking cores, dramatically increasing the cost of large-scale attacks.

Determinism and Verification

KDFs are deterministic: the same input password, salt, and parameters always produce the same output key. This property is essential for password verification, where the server re-derives the key from the candidate password and compares it to the stored value using a constant-time comparison to prevent timing attacks. For key agreement scenarios, both parties derive the same session keys from the shared secret without ever transmitting the keys themselves.

3. Implementation

Implementing KDFs correctly requires using well-vetted libraries rather than building custom constructions. In Python, the standard library provides hashlib.pbkdf2_hmac, while hashlib.scrypt is available from Python 3.6 onward. For Argon2 and bcrypt, the argon2-cffi and bcrypt packages are the recommended choices. Never implement a KDF from primitive hash operations in production code; subtle errors in iteration handling or salt management can completely undermine security.

The following examples demonstrate secure, production-oriented usage with appropriate parameter choices as of 2025-2026. Note that parameters should be periodically re-evaluated as hardware improves.

import hashlib
import os
import hmac

def derive_pbkdf2_key(password: str, salt: bytes = None, iterations: int = 600000) -> tuple[bytes, bytes]:
    """
    Derive a 32-byte key using PBKDF2-HMAC-SHA256.
    OWASP recommends at least 600,000 iterations for PBKDF2-HMAC-SHA256.
    """
    if salt is None:
        salt = os.urandom(16)  # 128-bit salt, unique per password
    
    if len(password.encode('utf-8')) < 8:
        raise ValueError("Password should be at least 8 characters")
    
    # hashlib.pbkdf2_hmac handles iteration and HMAC chaining internally
    derived_key = hashlib.pbkdf2_hmac(
        'sha256',
        password.encode('utf-8'),
        salt,
        iterations,
        dklen=32  # 256-bit output for AES-256
    )
    return derived_key, salt

def verify_pbkdf2_password(candidate: str, salt: bytes, expected_key: bytes, iterations: int = 600000) -> bool:
    """Verify candidate password using constant-time comparison."""
    candidate_key, _ = derive_pbkdf2_key(candidate, salt, iterations)
    # hmac.compare_digest prevents timing attacks
    return hmac.compare_digest(candidate_key, expected_key)

# Example usage
key, salt = derive_pbkdf2_key("correct horse battery staple")
print(f"Salt: {salt.hex()}")
print(f"Key: {key.hex()}")
print(f"Verified: {verify_pbkdf2_password('correct horse battery staple', salt, key)}")

import hashlib
import hmac
import os

def hkdf_extract(salt: bytes, input_key_material: bytes) -> bytes:
    """HKDF-Extract: concentrates entropy into a pseudorandom key (PRK)."""
    if salt is None or len(salt) == 0:
        salt = bytes([0] * 32)  # RFC 5869: zero-filled salt if not provided
    return hmac.new(salt, input_key_material, hashlib.sha256).digest()

def hkdf_expand(prk: bytes, info: bytes, length: int) -> bytes:
    """HKDF-Expand: expands PRK into output key material of desired length."""
    if length > 255 * 32:
        raise ValueError("Cannot expand to more than 255*HashLen bytes")
    
    output = b""
    previous_block = b""
    counter = 1
    
    while len(output) < length:
        # T(n) = HMAC-Hash(PRK, T(n-1) | info | counter)
        data = previous_block + info + bytes([counter])
        previous_block = hmac.new(prk, data, hashlib.sha256).digest()
        output += previous_block
        counter += 1
    
    return output[:length]

def hkdf(salt: bytes, ikm: bytes, info: bytes, length: int) -> bytes:
    """Full HKDF: Extract then Expand."""
    prk = hkdf_extract(salt, ikm)
    return hkdf_expand(prk, info, length)

# Derive multiple independent keys from one master secret
master_secret = os.urandom(32)
salt = os.urandom(16)

# Domain separation via 'info' parameter
enc_key = hkdf(salt, master_secret, b"aes-256-gcm encryption key", 32)
mac_key = hkdf(salt, master_secret, b"hmac-sha256 auth key", 32)
print(f"Enc Key: {enc_key.hex()}")
print(f"MAC Key: {mac_key.hex()}")
# enc_key and mac_key are cryptographically independent

import hashlib
import os

def derive_scrypt_key(password: str, salt: bytes = None) -> tuple[bytes, bytes]:
    """
    Derive key using scrypt - memory-hard KDF.
    Parameters: N=2^15, r=8, p=1 uses ~32MB memory, ~200ms on modern CPU.
    """
    if salt is None:
        salt = os.urandom(16)
    
    # N must be power of 2, r=block size, p=parallelization
    # N=32768, r=8, p=1 is a balanced choice for interactive logins
    derived_key = hashlib.scrypt(
        password.encode('utf-8'),
        salt=salt,
        n=32768,  # CPU/memory cost (must be power of 2)
        r=8,      # block size
        p=1,      # parallelization factor
        dklen=32
    )
    return derived_key, salt

# Argon2id example using argon2-cffi (pip install argon2-cffi)
# Argon2id is the recommended variant: hybrid of Argon2i and Argon2d
try:
    from argon2 import PasswordHasher
    from argon2.low_level import hash_secret, Type

    ph = PasswordHasher(
        time_cost=3,      # number of iterations
        memory_cost=65536, # 64 MiB
        parallelism=4,    # 4 parallel threads
        hash_len=32,
        salt_len=16
    )

    hash_str = ph.hash("user_password_123")
    print(f"Argon2 hash: {hash_str}")
    # Verification raises exception if invalid
    ph.verify(hash_str, "user_password_123")
    print("Argon2 verification succeeded")

    # Low-level API for raw key derivation
    raw_key = hash_secret(
        b"master secret",
        os.urandom(16),
        time_cost=3,
        memory_cost=65536,
        parallelism=4,
        hash_len=32,
        type=Type.ID
    )
    print(f"Argon2id raw key: {raw_key.hex()}")
except ImportError:
    print("argon2-cffi not installed, skipping Argon2 demo")

# Demonstrate that scrypt with small N is fast but weak
weak_key = hashlib.scrypt(b"password", salt=b"NaCl", n=1024, r=8, p=1, dklen=32)
print(f"Weak scrypt (N=1024): {weak_key.hex()[:16]}...")

import hashlib
import os
import hmac

def secure_key_derivation_pipeline(user_password: str) -> dict:
    """
    Complete pipeline: password -> KDF -> storage format with versioning.
    Demonstrates best practices: random salt, pepper, versioning, and upgrade path.
    """
    # Pepper stored separately, e.g., in environment variable or HSM
    # In production, load from secure config, not hardcoded
    PEPPER = os.environ.get("APP_PEPPER", "default-pepper-change-me").encode()

    salt = os.urandom(16)
    # Combine password and pepper before KDF
    peppered_password = hmac.new(PEPPER, user_password.encode(), hashlib.sha256).digest()

    # Use scrypt for storage; parameters stored alongside hash for future upgrades
    params = {"n": 32768, "r": 8, "p": 1, "dklen": 32}
    derived = hashlib.scrypt(peppered_password, salt=salt, **params)

    # Store as modular format: $algorithm$param1$param2$salt$hash
    # This allows transparent upgrades when parameters change
    stored_record = {
        "algorithm": "scrypt",
        "params": params,
        "salt": salt.hex(),
        "hash": derived.hex(),
        "version": 1
    }
    return stored_record

def needs_rehash(stored_record: dict, current_params: dict) -> bool:
    """Check if stored hash uses outdated parameters and should be rehashed on next login."""
    if stored_record["params"]["n"] < current_params["n"]:
        return True
    if stored_record["params"]["r"] != current_params["r"]:
        return True
    return False

# Simulate user registration and login
record = secure_key_derivation_pipeline("MyStr0ng!Pass")
print(f"Stored record: {record}")

# On login, verify and check if upgrade needed
current_params = {"n": 65536, "r": 8, "p": 1, "dklen": 32}
if needs_rehash(record, current_params):
    print("Hash parameters outdated - will rehash after successful verification")

4. Step-by-Step Example

To make the abstract mechanism concrete, let us walk through a complete PBKDF2-HMAC-SHA256 derivation with simplified parameters. Suppose a user registers with the password flyfish2024! and the system generates a random 16-byte salt 0x73616c745f31325f627974657321 (ASCII for "salt_12_bytes!"). The system is configured to use 600,000 iterations and produce a 32-byte key.

Step 1 is encoding. The password is encoded as UTF-8 bytes: 66 6c 79 66 69 73 68 32 30 32 34 21. The salt remains as raw bytes. No trimming or lowercasing is performed; passwords are case-sensitive and whitespace is preserved, as altering the input would reduce entropy and create interoperability issues.

Step 2 begins the iterative HMAC chain. PBKDF2 computes U1 = HMAC-SHA256(Password, Salt || INT(1)), where INT(1) is the 4-byte big-endian block index. For a 32-byte output with SHA-256 (which outputs 32 bytes), only one block is needed, so the index is always 1. The result U1 is a 32-byte pseudorandom value. Then for each subsequent iteration i from 2 to 600,000, it computes Ui = HMAC-SHA256(Password, U(i-1)). Each Ui depends on the previous output, creating a sequential chain that cannot be parallelized.

Step 3 is the final combination. After all 600,000 iterations, the derived key is the XOR of all Ui values: DK = U1 XOR U2 XOR ... XOR U600000. This XOR accumulation ensures that every iteration contributes to the final output. If an attacker tries to skip iterations, the result will be incorrect. The final 32-byte value, for example a3f5c1d9e8b2..., is stored alongside the salt and iteration count. The original password is immediately discarded from memory, ideally by overwriting the buffer.

Verification mirrors this process exactly. When the user later logs in with a candidate password, the system retrieves the stored salt and iteration count, re-runs the identical PBKDF2 computation, and compares the newly derived key to the stored key using a constant-time function. If the comparison succeeds, authentication is granted. If the stored parameters are outdated, the system can transparently re-derive with stronger parameters and update the database, providing a seamless upgrade path without requiring a password reset.

Tracing HKDF Expansion

Consider HKDF used after an ECDH key exchange. The shared secret IKM = 0x8d43... (32 bytes) and a salt are fed to HKDF-Extract to produce a 32-byte PRK. To derive a 64-byte output for two keys, HKDF-Expand computes T1 = HMAC(PRK, info || 0x01) and T2 = HMAC(PRK, T1 || info || 0x02), concatenating T1 and T2. Using distinct info strings like "handshake key" and "application key" guarantees that even if one derived key is compromised, the other remains secure due to the PRF's domain separation.

5. Complexity Analysis

The computational complexity of key derivation functions is intentionally parameterized, unlike typical algorithms where complexity is an inherent property. The defender chooses the cost to balance security and usability, while the attacker must pay that cost for every password guess. This makes Big O analysis nuanced: we analyze cost per derivation as a function of the tunable parameters rather than input size alone.

For PBKDF2 with iteration count c and hash function cost h, the time complexity is O(c * h). Since h is constant for a given hash, time scales linearly with c. Doubling iterations doubles both defender and attacker time. Space complexity is O(1) beyond the hash state, which is why PBKDF2 is not memory-hard and is vulnerable to GPU acceleration.

For memory-hard functions like scrypt and Argon2, time complexity is O(N * r * p) and space complexity is O(N * r), where N is the memory cost parameter, r is block size, and p is parallelism. Crucially, an attacker attempting to reduce memory usage faces a time-memory tradeoff that increases time complexity superlinearly. Argon2 is designed so that reducing memory by a factor of 4 increases time by a factor that makes the tradeoff uneconomical, forcing attackers to use the full memory.

HKDF, by contrast, is designed to be fast because its input is already high-entropy. Its complexity is O(n) where n is the number of hash blocks needed for the output length, with O(1) space. It should never be used directly with passwords, as its speed would make brute-force trivial.

In practical terms, a PBKDF2 derivation with 600,000 iterations takes approximately 150-300 milliseconds on a modern server CPU, while an attacker with an RTX 4090 GPU can attempt roughly 50,000 guesses per second per GPU for weaker settings, but only a few hundred per second at the recommended 600,000 iterations. Argon2id with 64 MiB and 3 iterations takes similar wall-clock time for the defender but reduces attacker GPU throughput by 2-3 orders of magnitude due to memory bandwidth constraints.

6. Variations and Optimizations

The KDF landscape has evolved significantly from early iterated hashing to modern memory-hard designs. PBKDF2, standardized in RFC 2898 and PKCS #5, remains widely supported and FIPS 140-2 approved, making it a safe choice for compliance-sensitive environments. Its main optimization is the ability to parallelize block computations when deriving keys longer than the hash output, though for password hashing the output is typically one block so this offers little benefit.

bcrypt, based on the Eksblowfish algorithm from 1999, introduced adaptive cost via its log2 iteration parameter. Increasing cost from 10 to 12 doubles the time, allowing the work factor to grow with Moore's Law. bcrypt truncates passwords at 72 bytes, a limitation that can be mitigated by pre-hashing long passwords with SHA-256 before bcrypt. It also has a 192-bit salt and outputs a 184-bit hash, and its use of a modified Base64 encoding requires careful implementation.

scrypt, introduced by Colin Percival in 2009, was the first to formalize memory hardness. Its ROMix function fills a large array with pseudorandom data derived from the password and salt, then accesses it in a pseudorandom order. This sequential memory-hard property ensures that any implementation must either use the full memory or incur a substantial time penalty. Optimized variants like yescrypt and Lyra2 improve on scrypt's cache-timing resistance and parallelism.

Argon2 is the current state of the art, offering three variants: Argon2d maximizes resistance to GPU cracking by using data-dependent memory access, Argon2i uses data-independent access to resist side-channel attacks, and Argon2id is a hybrid that provides both. Argon2id is the recommended default for password hashing. It also supports additional inputs such as associated data, secret pepper, and versioning, and it allows the defender to tune memory, iterations, and parallelism independently to match the deployment environment, whether it is a memory-constrained IoT device or a high-memory server.

Balloon Hashing and Future Directions

Balloon hashing, another finalist in the Password Hashing Competition, offers provable memory-hardness guarantees in the random-oracle model and is simpler to implement correctly than Argon2. While less widely deployed, it is used in some blockchain and cryptocurrency applications where formal proofs are valued. Research continues into KDFs that are resistant to quantum attacks and that provide better performance on constrained hardware without sacrificing memory hardness.

7. Real-World Applications

Key derivation functions are ubiquitous in modern infrastructure, often operating invisibly to end users. In web applications, every major framework including Django, Ruby on Rails, and Spring Security uses a KDF for password storage. Django defaults to PBKDF2-HMAC-SHA256 with 720,000 iterations, while newer frameworks like Phoenix and Node.js libraries increasingly default to Argon2id. When a data breach exposes a database of properly KDF-hashed passwords, the cost of cracking forces attackers to focus only on weak, common passwords, protecting users with strong passphrases.

In network security, KDFs are central to key agreement protocols. TLS 1.3 uses HKDF to derive handshake keys, application traffic keys, and resumption keys from the shared secret established via ECDHE. Each derived key has a distinct info label, ensuring cryptographic separation between different stages of the connection. Similarly, the Signal Protocol uses HKDF to ratchet forward message keys, providing forward secrecy so that compromise of a current key does not reveal past messages. WPA3 for Wi-Fi uses Dragonfly handshake with a KDF to derive the Pairwise Master Key from the password, mitigating offline dictionary attacks that plagued WPA2.

Full-disk and file encryption systems rely heavily on KDFs to transform user passphrases into encryption keys. LUKS for Linux, FileVault for macOS, and BitLocker for Windows all use PBKDF2 or Argon2 to derive the key that encrypts the master key, which in turn encrypts the disk. Cryptocurrency wallets use PBKDF2 and scrypt as part of BIP39 mnemonic seed derivation, where a 12-24 word phrase is stretched into a 512-bit seed that generates all private keys. A weak KDF in this context would allow attackers to brute-force mnemonic phrases and steal funds.

Cloud infrastructure also leverages KDFs for key management. Services like AWS KMS and HashiCorp Vault use HKDF to derive per-tenant or per-object encryption keys from a master key, enabling key rotation and hierarchical key management without re-encrypting all data. This pattern, known as key wrapping or key diversification, limits the blast radius if a derived key is exposed.

8. Comparison with Alternatives

Choosing the right KDF requires understanding the threat model and the entropy of the input. Not all KDFs are interchangeable, and using a fast KDF where a slow one is needed, or vice versa, can create critical vulnerabilities or performance bottlenecks. The table below provides a feature-level comparison to guide selection.

Fast, non-iterated hashes like raw SHA-256 or SHA-512 should never be used for password storage, despite their prevalence in legacy systems and naive tutorials. They offer no iteration, no salt handling, and no memory hardness, allowing attackers to try billions of guesses per second. Even a single iteration of HMAC is insufficient; the iteration count must be high enough to make brute-force economically infeasible.

Key stretching via simple iteration, such as applying SHA-256 10,000 times in a loop without HMAC, is also insecure due to length-extension and collision issues. PBKDF2 fixes this by using HMAC as its PRF, which is proven to be a secure construction even when the underlying hash has weaknesses. Similarly, using HKDF with a password is a category error: HKDF is designed for high-entropy inputs and will derive keys quickly, offering no protection for weak passwords.

For new systems handling passwords, Argon2id is the clear recommendation from OWASP, IETF, and the Password Hashing Competition. If Argon2 is unavailable, scrypt is the next best choice, followed by bcrypt and finally PBKDF2 for environments requiring FIPS certification. For deriving keys from already-strong material like a 256-bit master key or ECDH output, HKDF is the correct and most efficient choice.

9. Common Mistakes and Best Practices

Even with a secure KDF, implementation errors can nullify its protections. The most common mistake is using insufficient iteration or memory parameters, often by accepting library defaults that are outdated. For example, PBKDF2 with 1,000 iterations, the default in some older libraries, is trivially crackable today. Always configure parameters to achieve at least 200-500 ms per derivation on your production hardware and review them annually as hardware improves.

Reusing salts or using predictable salts is another critical flaw. Salts must be generated with a cryptographically secure random number generator and must be unique per password. Using the username, email, or a fixed application-wide salt defeats the purpose of salting and enables rainbow table and cross-user attacks. Salts do not need to be secret and should be stored alongside the hash, but they must be random and at least 128 bits long.

Failing to use constant-time comparison during verification leaks information through timing side channels. A naive string comparison that returns early on the first mismatched byte allows an attacker to guess the hash byte-by-byte by measuring response time. Always use hmac.compare_digest in Python or equivalent constant-time functions in other languages. Similarly, error messages should not reveal whether a username exists or whether the password was incorrect; both cases should return identical generic responses with similar timing.

Other pitfalls include truncating or transforming passwords before hashing, such as lowercasing, trimming whitespace, or limiting length without pre-hashing, which reduces entropy. Storing KDF parameters separately from the hash makes upgrades difficult; instead, store the full modular crypt format that includes algorithm, parameters, salt, and hash together. Finally, never implement your own KDF or modify a standard one, such as by adding custom mixing steps, as this often introduces vulnerabilities without improving security. Use peer-reviewed, standardized constructions with well-audited libraries.

Best Practice Checklist

• Use Argon2id for new password hashing; use HKDF for high-entropy key derivation
• Generate a unique 16+ byte salt per password with os.urandom or secrets.token_bytes
• Configure parameters to target 200-500 ms per hash on production hardware
• Store algorithm, parameters, salt, and hash together for future upgrades
• Verify with constant-time comparison and generic error messages
• Support transparent rehashing: upgrade parameters on next successful login
• Consider a pepper stored in an HSM or environment variable for defense-in-depth
• Enforce password strength requirements and rate-limit authentication attempts

10. Interview Questions

Key derivation functions are a frequent topic in security and backend engineering interviews because they test understanding of both cryptography and practical system design. Below are common questions with guidance on what interviewers expect.

Q1: Why can't we just use SHA-256 to hash passwords?

Answer: SHA-256 is designed to be fast, processing billions of hashes per second on GPUs. An attacker who steals a database of SHA-256 password hashes can brute-force common passwords in seconds using dictionary and rainbow table attacks. KDFs like bcrypt, scrypt, and Argon2 are intentionally slow and, in the case of scrypt and Argon2, memory-hard, making each guess expensive. Additionally, SHA-256 alone does not handle salting automatically, so identical passwords would produce identical hashes, leaking information. A proper KDF adds unique salts, tunable cost, and output flexibility, raising the attacker's cost by many orders of magnitude while keeping defender cost acceptable.

Q2: Explain the difference between PBKDF2, bcrypt, scrypt, and Argon2. When would you choose each?

Answer: PBKDF2 is CPU-hard only, with tunable iterations, FIPS-approved but vulnerable to GPU/ASIC acceleration due to low memory usage. bcrypt is also CPU-hard, based on Blowfish, with a log cost factor, but limited to 72-byte passwords and fixed output. scrypt adds memory hardness with tunable N, r, p parameters, requiring significant RAM per guess. Argon2id, the current recommended choice, provides tunable time, memory, and parallelism, with hybrid data-dependent and independent access for both GPU and side-channel resistance. Choose Argon2id for new systems, scrypt as a strong alternative, bcrypt for legacy compatibility, PBKDF2 when FIPS compliance is required, and HKDF only for high-entropy inputs like key agreement secrets, never for passwords.

Q3: What is a salt and why must it be unique per password? What about pepper?

Answer: A salt is a random, non-secret value unique per derivation that is combined with the password before hashing. It ensures that identical passwords yield different hashes, defeating rainbow tables and forcing attackers to attack each hash individually. Salts must be generated with a CSPRNG, be at least 128 bits, and be stored alongside the hash. A pepper is a secret, application-wide value stored separately from the database, often in an HSM, added to the password before hashing. If the database is compromised but the pepper is not, the hashes remain protected. Unlike salts, peppers are not stored per-user and must be rotated carefully.

Q4: How do you decide on KDF parameters like iterations or memory cost?

Answer: Parameters should be chosen to make derivation take 200-500 ms on production hardware, balancing security and user experience. Benchmark on the actual deployment environment, not a developer laptop, because server CPUs differ. For PBKDF2-HMAC-SHA256, OWASP recommends at least 600,000 iterations; for bcrypt, cost 12 or higher; for scrypt, N=32768, r=8, p=1 (~32 MB); for Argon2id, memory 64 MiB, time 3, parallelism 4 as a starting point. Parameters should be stored with the hash and reviewed annually, with transparent rehashing on next login when stronger parameters are adopted. Also consider DoS risk: excessively high parameters can be abused to overload the server, so rate-limit authentication endpoints.

Q5: What is HKDF and how does its extract-then-expand model work?

Answer: HKDF is a KDF based on HMAC, standardized in RFC 5869, designed for high-entropy inputs like ECDH shared secrets. It has two stages: Extract concentrates potentially non-uniform input key material into a fixed-length pseudorandom key using HMAC with a salt, and Expand stretches that PRK into arbitrary-length output using HMAC with an info string and counter. The info parameter provides domain separation, allowing one master secret to derive multiple independent keys. HKDF is fast by design and must not be used with low-entropy passwords, where a slow, memory-hard KDF is required. In TLS 1.3, HKDF is used to derive separate handshake and application keys from the same shared secret.