What Is PBKDF2 and Why Does It Matter for Your Crypto Security?

The Problem: Passwords Are Not Cryptographic Keys

When you choose a password like "SeedCrypt2026!" to encrypt your seed phrase, that string is not, as-is, a usable AES-256 encryption key. AES-256 requires a precisely 256-bit (32-byte) key, and it expects that key to have high entropy (randomness) distributed throughout all its bits.

A human-chosen password typically has far less entropy than a fully random 256-bit key. A 16-character mixed-case alphanumeric password has roughly 95 bits of entropy at best, significantly less than the 256 bits AES-256 is designed to use. Simply hashing the password once and using the hash as a key is not sufficient either, because a single hash operation is extremely fast; modern GPUs can compute billions of SHA-256 hashes per second.

This is where key derivation functions (KDFs) come in. Their job is to transform a human-memorizable password into a proper cryptographic key while making the transformation computationally expensive enough to defeat brute-force attacks.

What Is PBKDF2?

PBKDF2 stands for Password-Based Key Derivation Function 2. It was defined in RFC 2898 and is standardized by NIST as part of SP 800-132. It takes a password, a random salt, and a configurable iteration count as inputs, and produces a derived key of any desired length as output.

The core operation is simple to understand: it applies a pseudorandom function (typically HMAC with a hash algorithm like SHA-512) repeatedly for a specified number of iterations. Each iteration takes the output of the previous one as input. After all iterations complete, the final result is used as the encryption key.

The role of the salt

The salt is a random value generated fresh for each encryption operation and stored alongside the ciphertext. It ensures that two users with the same password produce completely different derived keys, preventing precomputed lookup tables (rainbow tables) from being used to attack multiple targets simultaneously. It also means an attacker cannot precompute keys before obtaining the ciphertext; they must start the derivation from scratch for each individual target.

SeedCrypt uses a 256-bit random salt, which provides more than enough protection against any rainbow table or precomputation attack.

The iteration count

The iteration count is what directly determines the computational cost of deriving a key. A higher count means each password guess by an attacker requires more work. SeedCrypt uses 600,000 iterations of PBKDF2-SHA512.

Why 600,000 Iterations?

The NIST 2023 guidelines recommend a minimum of 600,000 iterations for PBKDF2-SHA256 when used for password hashing. For SHA-512 (which is slower per iteration on most hardware), the equivalent protection is achieved with somewhat fewer iterations, but SeedCrypt uses 600,000 to match the current NIST recommendation with additional margin.

In practice terms: a modern consumer GPU can compute approximately 400,000 PBKDF2-SHA512 iterations per second. With 600,000 iterations per password guess, an attacker can try roughly 0.67 password guesses per second per GPU.

A typical targeted attack might have access to 100 high-end GPUs. That is approximately 67 password guesses per second. For a password using 12 characters from a character set of 72 (lowercase, uppercase, digits, common symbols), the search space is roughly 72^12 ≈ 19 quadrillion possible passwords. At 67 guesses per second, exhausting that search space would take approximately 9 billion years.

Even a shorter 10-character password with the same character set would take over 2 million years to exhaust. The iteration count transforms a practically limited password into something computationally irreversible to brute-force.

SHA-512 vs SHA-256 for PBKDF2

SeedCrypt uses PBKDF2-SHA512 rather than the more common PBKDF2-SHA256 for two reasons. First, output length: SHA-512 produces a 512-bit hash, which is sufficient to derive both a 256-bit AES key and a 256-bit salt in a single derivation call without any additional stretching. Second, hardware asymmetry: SHA-512 is natively fast on 64-bit CPUs but runs relatively slowly on GPU and ASIC hardware. Since modern attackers primarily rely on GPU farms for brute-force, SHA-512 imposes a proportionally higher cost on them than on the legitimate user decrypting on a standard CPU.

This is a meaningful practical advantage. The same 600,000 iterations costs more in attacker infrastructure than it costs the user in decryption wait time (which is typically under one second on any modern device).

PBKDF2 vs Argon2 vs bcrypt

Cryptographers debate the relative merits of different KDFs. Argon2 (the winner of the Password Hashing Competition in 2015) and bcrypt are frequently mentioned as alternatives to PBKDF2.

Argon2 has a genuine advantage: it is memory-hard, meaning it requires large amounts of RAM per guess in addition to CPU cycles. This significantly limits the effectiveness of GPU and ASIC attacks that benefit from high parallelism but typically have limited RAM per compute unit. For the highest-security applications, Argon2id is currently the recommended choice.

PBKDF2-SHA512 at 600,000 iterations remains a well-understood, widely deployed, NIST-standardized standard that provides strong security for the typical threat model of a password-encrypted backup. It is not the state-of-the-art, but it is well above the minimum bar and has extensive real-world security analysis supporting it.

What This Means in Practice for Seed Phrase Security

When you use SeedCrypt to encrypt your seed phrase, a random 256-bit salt is generated for that specific encryption. Your password is then run through PBKDF2-SHA512 with 600,000 iterations combined with that salt, producing a 256-bit AES key that is used directly for AES-256-GCM encryption. The salt and the authentication tag are stored alongside the ciphertext so that decryption can reproduce the same derived key.

An attacker who obtains your encrypted backup sees the salt and ciphertext. They must run PBKDF2-SHA512 with 600,000 iterations for every password guess. With any reasonably complex password (12+ mixed characters), this is computationally infeasible given any realistic attacker resources.

The salt ensures that even if another SeedCrypt user happened to choose the same password, your encrypted backup would use a completely different key. There is no shared-password vulnerability.

Conclusion

PBKDF2 is the mechanism that makes password-based encryption viable for protecting valuable secrets like seed phrases. Without it, even AES-256 encryption would be vulnerable to brute-force attacks against typical user passwords. With it, the computational cost of guessing passwords is raised to levels that make attacks economically and computationally infeasible for any realistic attacker.

Understanding PBKDF2 helps you understand why password strength still matters: longer, more complex passwords raise the attacker's cost further, and why the combination of a good password plus 600,000 PBKDF2 iterations provides a robust foundation for long-term seed phrase security.