Where it fits
The Bitcoin Core extractor parses compatible encrypted wallets stored as Berkeley DB wallet.dat
files or SQLite descriptor wallets. Before emitting a safe test piece, this specific extractor checks
that the wallet is encrypted, uses the supported password derivation method, and contains at least
one usable encrypted key record.
Unsupported or malformed files fail closed instead of producing an operator artifact that cannot be verified later.
Safe test piece
Bitcoin Core’s mkey record contains a random 32-byte wallet encryption key, encrypted under the
user’s password. Bitcoin Core internals often call this value the wallet master key, but it is not
a BIP32/HD master private key, wallet seed, or Bitcoin signing key. It is a symmetric key used to
encrypt private-key records elsewhere in the wallet.
The safe test piece is the standard hashcat mode 11300 representation containing:
- the complete password-encrypted wallet encryption key, normally 48 bytes after AES-CBC padding;
- the 8-byte password-derivation salt;
- the wallet’s iteration count;
- empty placeholders where an example encrypted private key and public key could otherwise appear.
In compact form:
$bitcoin$<encrypted-wallet-key>$<salt>$<iterations>$<no-ckey>$<no-pubkey>The actual wire format also carries field lengths. Distribrute emits the conventional 2$00$2$00
placeholder for the omitted key pair.
No ckey, descriptor encrypted-key record, public key, address, or unrelated wallet database record
is sent to the operator fleet.
Why the wallet encryption key is not spendable
A correct password lets the search tool decrypt the 32-byte wallet encryption key. That value is sensitive, but it is not a Bitcoin private key, an HD root key, or a source from which wallet keys can be derived. It cannot sign a transaction by itself.
To reach a spendable private key, an attacker also needs an encrypted private-key record from the original wallet. Those records are deliberately absent from the safe test piece. The fleet receives one side of the relationship, never both.
Password test
Bitcoin Core’s CCrypter derives an AES key and IV by repeatedly hashing the password and salt with
SHA-512. This is Bitcoin Core’s iterative SHA-512 derivation, not PBKDF2.
The derived AES-256 key and IV decrypt the encrypted wallet encryption key in CBC mode. A candidate is an operator-side match when PKCS#7 unpadding yields the expected 32-byte key shape.
Valid padding alone is not sufficient ground truth. A wrong password can very rarely produce plausible padding.
Full-wallet verification
Verify repeats the password derivation using the candidate and the full wallet held inside the authorized boundary. It then:
- decrypts a real encrypted private-key record with the recovered wallet encryption key;
- obtains the 32-byte private key;
- derives its Bitcoin public key;
- compares that result with the public key stored in the wallet.
The candidate is accepted only if the public keys match. A padding-only wallet-encryption-key result is never treated as a verified recovery.
For a non-custodial case, the same proof must ultimately be performed against the owner’s full wallet on the owner-controlled computer.
Public wallet data and transaction preparation
Some Bitcoin Core wallet files expose public records even while private material remains encrypted. Where the file and wallet type permit it, those records may help identify destinations or prepare an unsigned transaction before unlock. They are workflow inputs inside the authorized recovery boundary; they are not added to the operator safe test piece.
Final transaction details still require explicit review because wallet type, change handling, fees, and available coins vary by case.
Security properties and limits
- Operators do not receive encrypted private-key records or the public keys that validate them.
- Recovering the wallet encryption key from the extract alone does not provide a signing key.
- Full verification requires a real wallet key to decrypt and a matching public key to re-derive.
- Only supported encrypted wallet structures and derivation method 0 are accepted.
- Historical or damaged wallets may require case-specific analysis before admission.
- The engine recovers a wallet password; cases without a usable encrypted wallet are covered in What we cannot recover.
For the general boundary, see Safe test pieces.