Where it fits
This engine handles compatible encrypted backups from Blockchain.com and its earlier Blockchain.info wallet formats. The input may be a local encrypted backup or, for some cases, an identifier from which the encrypted backup can be retrieved during controlled intake.
The wallet version is checked before a case is accepted. A Blockchain.com account, seed phrase, or login session is not a substitute for a compatible encrypted wallet backup.
Safe test piece
The operator artifact contains exactly one AES ciphertext block:
"bk:" || ciphertext[0:16] || iv[0:16] || iteration_count_u32_le || crc32_u32_leThe decoded bytes are Base64-encoded with the $blockchainx$ format marker. The CRC is a cheap
format guard; protocol integrity comes from the SHA-256 digest bound into the signed case manifest.
The IV also serves as the password-derivation salt. The artifact does not contain later ciphertext blocks.
Why exactly one block
With a correct password, the first decrypted block contains a recognizable beginning of the wallet JSON. It may reveal a small plaintext prefix, but it cannot contain the complete wallet GUID. Adding a second block would expose a much larger part of that GUID.
That matters for historical Blockchain.info wallets: a sufficiently complete GUID may be usable to retrieve the encrypted remote wallet. Keeping only one block prevents the safe test piece from becoming a route back to the full encrypted backup.
The one-block artifact also omits the encrypted payload containing addresses, private keys, and the rest of the wallet structure. It is useful for testing a password, not for reconstructing the wallet.
Password test
The engine derives a 256-bit AES key using PBKDF2-HMAC-SHA-1 with the password and stored IV.
- For versioned wallets, it uses AES-256-CBC and the iteration count stored with the wallet.
- For legacy wallets, the format uses a sentinel value and the engine checks the known historical combinations: CBC with 10 rounds, CBC with 1 round, and OFB with 1 round.
The engine decrypts only the one available block and looks for known wallet-JSON field fragments such
as "guid", "sharedKey", or "keys". A wrong password normally produces random bytes rather than
one of these structures.
Verification strength
A one-block keyword match is probabilistic. It is strong enough to identify a likely candidate, but it is not equivalent to opening and parsing the entire wallet.
| Custody mode | Final check |
|---|---|
| Custodial | Verify decrypts the full stored payload and checks valid wallet structure |
| Non-custodial | Verify confirms the one-block result; the owner’s local full-wallet decrypt remains the final ground truth |
An operator report is never accepted solely because the GPU tool printed a match.
Addresses and transaction construction
The encrypted backup does not reliably expose the usable public addresses before it is decrypted. Unlike some Bitcoin Core files, this means the final transaction generally cannot be prepared from public wallet records at onboarding. Address discovery and transaction construction happen after the password has opened the full wallet in the authorized recovery environment.
This is one reason the non-custodial ceremony must be wallet-aware rather than a generic signing script.
Security properties and limits
- Operators receive one ciphertext block, never the full encrypted payload.
- The artifact does not carry a complete GUID, wallet addresses, or key-bearing wallet records.
- A correct candidate may expose the small plaintext represented by the first block.
- The minimal check can produce a false positive, so full-wallet proof remains necessary.
- Compatibility varies across historical backup formats and is evaluated during case review.
- The engine recovers the backup password; cases without a compatible encrypted backup are covered in What we cannot recover.
For the surrounding protocol, see Safe test pieces and End-to-end recovery.