Cryptography Reference

scrypt vs PBKDF2 — Key Derivation Functions Explained

If you've looked at an Ethereum keystore JSON file, you've seen a 'kdf' field set to either 'pbkdf2' or 'scrypt'. The choice between them isn't arbitrary — it determines how expensive each password attempt is on attacker hardware. For wallet owners trying to recover a forgotten password, the KDF is one of the two most important factors (alongside the password itself) determining whether recovery is realistic. This guide explains what each KDF does, why scrypt was designed, and what the practical recovery implications are.

What a KDF actually does

A key derivation function turns a low-entropy human password into a high-entropy cryptographic key suitable for AES or other ciphers. The basic idea: hash the password many times with a per-user salt, so attackers can't reuse precomputed rainbow tables and each candidate password attempt costs computational work.

PBKDF2 (Password-Based Key Derivation Function 2, RFC 2898) is the older, simpler design — iterate a hash function (HMAC-SHA1, HMAC-SHA256, HMAC-SHA512) for a configurable count, typically 10,000 to 1,000,000 iterations. The cost is purely CPU/GPU compute time per attempt.

scrypt (RFC 7914, Colin Percival 2009) is the memory-hard successor. In addition to compute work, scrypt requires a configurable amount of RAM per attempt — typically 16 MB to 1 GB. The memory requirement creates a fundamentally different cost model for attackers.

Why memory-hardness matters

Modern GPUs have massive parallel compute throughput but relatively limited per-thread memory bandwidth. PBKDF2 with SHA-256 verifies billions of candidate passwords per second on a high-end GPU because each thread only needs a few hundred bytes of state.

scrypt forces each parallel thread to hold a large memory buffer (typically 16 MB+). On the same GPU, you can only run as many threads in parallel as there's GPU memory available — typically thousands, not millions. The throughput drops by 3-4 orders of magnitude.

This memory-hardness was the explicit design goal. Custom ASICs that excel at parallel SHA-256 (like Bitcoin miners) provide minimal advantage against scrypt, because the bottleneck is RAM access patterns, not hash computation.

Why this matters for recovery

scrypt-protected wallets are roughly 100-1000x harder to recover than PBKDF2-protected wallets at the same password strength. This is the difference between 'recoverable in days' and 'recoverable in years'.

Wallet implementation choices

Bitcoin Core wallet.dat: SHA-512 iterated 25,000-50,000 times (auto-tuned at encryption time). Hashcat mode 11300. Closer to PBKDF2 in spirit but uses SHA-512 directly without HMAC.

Ethereum keystore (older geth, Mist): PBKDF2-HMAC-SHA256, default 262,144 iterations. Hashcat mode 15600. Per-password attempt is moderate cost — feasible recovery for typical passwords on multi-GPU clusters.

Ethereum keystore (geth 1.6+, modern wallets): scrypt with N=262144, r=8, p=1 (~256 MB RAM per attempt). Hashcat mode 15500. Substantially harder to recover at scale — strong protection.

MetaMask vault: PBKDF2-HMAC-SHA256 with only 10,000 iterations. Mode 26600. Browser performance constraint forces low iteration count — recovery for typical passwords is fast.

BIP39 seed derivation: PBKDF2-HMAC-SHA512 with 2,048 iterations. Used in every BIP39 wallet. The low iteration count combined with seed-level randomness makes brute force on the seed itself infeasible regardless of KDF cost.

What this means in practice

Two wallets with the same password but different KDFs have very different recovery profiles. A typical 8-character human password against PBKDF2-262144 might be recoverable on a multi-GPU cluster within hours. Against scrypt with the same parameters, it could take weeks of cluster time.

Stronger random passwords cross the 'practically infeasible' threshold sooner against scrypt than PBKDF2. A 12-character random password against PBKDF2 is borderline — multi-GPU cluster might succeed in months. Against scrypt, definitively infeasible on any reasonable budget.

When evaluating whether your forgotten wallet password is worth attempting recovery, the KDF check is the second-most-important data point (after the password itself). Open the keystore JSON in a text editor — the kdf field is at the top.

Why both KDFs still exist in 2026

PBKDF2 has the advantage of standardisation — it's specified in NIST SP 800-132, used in TLS, OpenSSL, hardware tokens. Compatibility with FIPS-validated cryptographic modules favours PBKDF2 in regulated environments.

scrypt provides better resistance against attackers with custom hardware (ASICs, FPGA) and large GPU clusters. For high-value password protection where cost is justified, scrypt is the modern default.

Argon2 (RFC 9106) is the newest design, winner of the Password Hashing Competition (2015). It combines memory-hardness with side-channel resistance. Used in some 2024+ wallet implementations but not yet widespread.

Recovery implications for wallet owners

Step 1: open your keystore JSON. The kdf field tells you the cost regime. Step 2: if pbkdf2 with low iteration count (under 100K), recovery for typical passwords is feasible. If scrypt with standard parameters, recovery is meaningfully harder. Step 3: assess your password's strength — random manager-generated passwords are out of reach regardless of KDF.

Pre-sale Ethereum wallets used scrypt-like parameters specifically because they protected high-value secrets. Bitcoin Core wallet.dat KDF is auto-tuned, so older files have weaker parameters than newer ones — your 2014 wallet is easier to recover than your 2024 wallet at the same password strength.

What the future holds

Modern wallet implementations are increasingly defaulting to scrypt or Argon2 for new wallets. Older PBKDF2-based wallets remain in circulation indefinitely because the encryption is fixed at file creation — there's no protocol-level upgrade path without decrypting first.

For wallet owners: protecting new wallets with strong random passwords + memory-hard KDFs (scrypt, Argon2) makes recovery essentially impossible if you forget — which is the security guarantee, but also the operational risk. Always have a separate backup of the seed phrase.

Frequently Asked Questions

Which is more secure: scrypt or PBKDF2?

scrypt is more secure against well-resourced attackers because of memory-hardness. For typical attackers with one or two GPUs, both are adequate at sufficient iteration counts. The difference matters most against industrial-scale recovery operations.

Can I tell which KDF my wallet uses?

Yes. Open the keystore JSON in any text editor. The 'kdf' field is at the top — values are 'pbkdf2' or 'scrypt'. The 'kdfparams' object below shows iteration count or scrypt's N/r/p parameters.

Why doesn't every wallet use Argon2?

Argon2 was standardised in 2021 (RFC 9106) — too late for most existing wallet implementations. New wallets (2024+) are starting to adopt it; legacy wallets remain on PBKDF2 or scrypt indefinitely.

Does the KDF affect quantum resistance?

Symmetric KDFs (PBKDF2, scrypt, Argon2) all suffer the same quantum threat: Grover's algorithm provides quadratic speedup against the underlying hash function. The KDF itself isn't quantum-vulnerable in the same way RSA is, but the effective security against quantum adversaries is half the classical security level.

If I have an old PBKDF2 wallet, can I migrate to scrypt?

Only by decrypting first (which requires the password) and re-encrypting with new parameters. There's no protocol-level conversion. After password recovery, you can re-encrypt with stronger parameters.

What about MetaMask's low iteration count?

10,000 is low because browsers must unlock instantly. The trade-off: convenient unlock vs slower brute force. For typical user passwords this is adequate; for high-entropy random passwords, the low iteration count doesn't matter because the password itself is the constraint.

Wallet recovery — free analysis

Forgotten password / passphrase / partial seed — run a free analysis to assess feasibility before any payment.

Run Free Analysis