Why some wallet passwords can be cracked and others can’t.

The key-derivation players: PBKDF2, scrypt, Argon2 and SHA-512

Almost every wallet uses one of these key-derivation approaches:

• PBKDF2 — repeatedly hashes the password with a salt. Costs are controlled by an iteration count (for Ethereum keystores the exact count is stored in the file’s kdfparams.c). Simple, but runs fast on GPUs.
• Repeated SHA-512 (wallet.dat) — Bitcoin Core’s own scheme, modelled on OpenSSL’s EVP_BytesToKey: the password and salt are hashed with SHA-512 over and over, with a rounds count chosen when the wallet was encrypted. The original baseline was ~25,000 rounds; btcrecover’s reference wallets measure ~68k to ~267k rounds. It also runs fast on GPUs.
• scrypt — memory-hard: it also forces a large block of memory, which makes GPUs and ASICs dramatically less efficient. BIP38 and Ethereum keystores use scrypt.
• Argon2 — the modern memory-hard KDF, used by newer password managers (KeePass 2 can use it) and some wallets. It is designed to be hostile to GPUs and ASICs; a strong Argon2-protected password is effectively unrecoverable by brute force.

All the parameters below are the real defaults of each format. You can verify a wallet file’s own parameters by reading its header — the wallet identifier shows how.

Version differences change the KDF

The same wallet name can hide very different encryption depending on the version — this is why “which version” matters before “which tool”:

Version claims above are verified against the wallet sources and the benchmark suite; see the master list for the per-wallet database.

What each wallet format actually does

Numbers matter: a low-round wallet.dat (~68k rounds, typical of old machines) runs about 4× faster per guess than a high-round one (~267k) — the count is machine-tuned, not a BDB-vs-SQLite rule. A BIP38 key (scrypt, heavy memory) is far slower per guess than a wallet with GPU-friendly key stretching — a single modern CPU checks only tens of BIP38 guesses per second, versus hundreds to low thousands of wallet.dat guesses.

What “crack speed” really means (measured)

These are measured figures from the btcrecover benchmark suite (Ryzen 9 9950X CPU, RTX 5090 GPU, 2026) — actual guesses per second on reference hardware, not marketing numbers:

Low-round wallet.dat rows are extrapolated from the 67,908-iteration measurement and marked as estimates; all other rows are published measurements. Want your own case modelled? Use the interactive strength calculator, which runs these same rates.

Reading the verdict from these numbers

• 8 characters of real randomness (say, a password-manager style string): effectively impossible for anyone, regardless of KDF.
• 8–12 characters you chose yourself (with a word, a date, a pattern): in principle recoverable if you can reconstruct the pattern — this is where memory reconstruction becomes the whole game.
• Short passwords are not automatically easy to brute-force. Feasibility depends on both the candidate space and the wallet’s per-guess cost — memory-hard formats such as BIP38 can make even short random passwords expensive to exhaust.
• A PIN (4–8 digits): trivially fast to brute-force if the encrypted file is in your hands — which is why hardware wallets wipe after a few wrong tries instead.

The full framework — including honest limits — is on when recovery is possible.

What the tools actually crack: the hash line

Cracking tools don’t attack the wallet file itself — they work on a small hash line extracted from it. That one line carries three things: the salt, the KDF parameters (which algorithm and how many iterations), and a verification value that only matches when the password is right. A wallet.dat hash line looks like $bitcoin$96$…; an Ethereum keystore is converted with ethereum2john.py, which produces the $ethereum$p*…/$ethereum$s*… hash line.

Two things follow from this. First, the hash line is not the wallet: it is not normally a plaintext private key, but for some formats it contains sensitive encrypted wallet material — treat it as sensitive as the wallet file itself. That is why extraction scripts like bitcoin2john.py or wallet2hashcat.py should run on a copy, and why recovery always happens offline. Second, the line’s format decides your tool: hashcat needs the converted line plus a mode number (11300, 12700, 15600…), John uses the *2john scripts, and btcrecover reads most wallets directly and does the extraction internally.

What this means for your case

• Do not delete the wallet file. Its KDF parameters and salt are the only reason cracking is possible at all.
• Gather memory clues, not guesses. A wordlist built from your patterns and habits beats blind brute force by orders of magnitude.
• Use offline tools on a copy. See offline recovery tools for btcrecover and hashcat — and why you should never upload the file to a public checker or unknown website.
• If the math says no, believe the math. A random 16-character password on a modern keystore is beyond every computer on Earth combined. No tool can change that.

Sources & references

1. Bitcoin Wiki — wallet encryption
2. hashcat — example hashes (wallet formats & modes)