Reference · version history
How wallet password encryption changed over time.
The same wallet name can hide very different encryption depending on the version — and the version decides how fast (or whether) recovery works. This page is the quick reference for what changed, when, and why it matters for your file.
By Robbert Bink · ~5 min read · Published 9 August 2026 · Last reviewed: 14 August 2026
Version first, tool second. A 2013 wallet.dat and a 2021 wallet.dat both call themselves wallet.dat — but one can test ~4× faster per guess. The same is true for Electrum, MultiBit and Blockchain.com files. This timeline shows the encryption changes that matter, so you can pin your file to its era before choosing a tool.
The timeline at a glance
| Wallet / format | Era | Encryption / KDF | What it means for recovery |
|---|---|---|---|
| Bitcoin Core wallet.dat | 2009–2011 | No built-in encryption | A wallet from this era was usually never encrypted — the password you remember may be irrelevant. |
| Bitcoin Core wallet.dat | 0.4 (2011) – 0.20 | AES-256-CBC + iterated SHA-512 (EVP_BytesToKey), ~25,000-round baseline, machine-tuned at encryption time | Old files often have fewer rounds — faster to test. The count is stored in the file, not fixed by the version. |
| Bitcoin Core wallet.dat | 0.21 (2021) – present | Same KDF; descriptor wallets use the SQLite backend (experimental in 0.21–22, default from 23.0) — legacy BDB wallets remain | Same encryption, typically higher rounds; hashcat mode 11300 unchanged. |
| Electrum | 1.x (2011–2014) | Double-SHA-256-based key scheme | Very weak by today’s standards — old Electrum files test fast. |
| Electrum | 2.0–2.7 (2015–early 2017) | Legacy keystore, double-SHA-256 family | Same weak family; extraction picks the salt type. |
| Electrum | 2.8+ (2017–present) | PBKDF2-SHA512 1,024 + ECC (BIE1 keystore) | Slower per guess; hashcat modes 21700/21800 by salt type. |
| MultiBit Classic | 2011–2016 | .key backup: 3×MD5 · .wallet file: scrypt N=16,384 | The .key backup is ~1,000× faster per guess — the classic “wrong file” trap. |
| MultiBit HD | 2014–2016 | scrypt N=16,384 r=8 p=1 | Much harder; the 12–24-word phrase restores without the password. |
| Ethereum keystore v3 | 2016–present | scrypt or PBKDF2-HMAC-SHA256; parameters stored in the file's kdfparams (geth commonly uses scrypt N=262,144, but lighter/non-default configurations exist) | Both slow; the JSON header names the KDF (hashcat 15700 vs 15600) — read the actual parameters before estimating speed. |
| MetaMask Extension — legacy vaults | 2016–present (legacy layout) | PBKDF2-HMAC-SHA256, 10,000 iterations fixed (hashcat 26600) | Fast per guess; the phrase is the faster path whenever you have it. |
| MetaMask Extension — newer vaults | Newer vault layouts (dynamic iteration counts) | PBKDF2-HMAC-SHA256, iteration count stored in the vault metadata — read the actual parameters instead of assuming 10,000 (dynamic-count mode 26610; 26620 only in newer/development hashcat builds) | Speed depends on the stored count — a 600,000-iteration vault is roughly 60× slower per guess than a 10,000 one; the phrase is the faster path whenever you have it. |
| MetaMask Mobile | Mobile app vaults | Separate vault format — PBKDF2-based with its own parameters (hashcat 31900) | Not the same as the extension vault — use the mobile-specific extraction and mode rather than applying extension parameters. |
| Blockchain.com | v0 (2011) / v2 / v3 (2020+) | PBKDF2-SHA1 at 10 / 10,000 / 5,000 iterations | The earliest exports are effectively unprotected; v2/v3 still crackable with clues. |
| BIP38 paper keys | 2012–present | scrypt N=16,384 r=8 p=8 | Memory-hard — tens of guesses per second; clues decide. |
| BIP39 passphrase | 2013–present | PBKDF2-HMAC-SHA512, 2,048 iterations; candidates verified by deriving target addresses | The “25th word” is a password problem, and a recoverable one with clues. |
Why the version decides your odds
Two passwords of identical length can sit in completely different recovery universes purely because of when the wallet was encrypted. The master list shows the current KDF per wallet, the benchmarks page shows the measured speeds, and the feasibility guide turns both into a verdict. The one thing this timeline adds is time: the era of your file is often the first and most reliable clue about its encryption.
How to find your version
- Bitcoin Core: the wallet version is visible in the client’s debug log and the wallet header; the wallet.dat guide explains the file versions.
- Electrum: let
electrum2john.pydetect the wallet format — for fully encrypted 2.8+ wallets it processes the encrypted container (base64BIE1prefix), not the JSON. The mode follows the generated$electrum$Nprefix: 1/2/3 → 16600, 4 → 21700, 5 → 21800. Since 2.8, the whole wallet file can be ECIES-encrypted on top of the internally encrypted seed — the extractor handles that layer. - Blockchain.com: the export filename and JSON structure identify v0/v2/v3.
- Not sure at all? The wallet-file identifier routes by extension and app first.
Sources & references
Keep going — it’s all free
Not sure what you lost or what’s possible?
Take the quick diagnosis for a first verdict — it stops early when the answer is already clear — then work the search checklist. Everything here is informative, runs offline, and is free to use.