How can I import a private key?

Question

I'm trying to get my coins out of an old MultiBit classic wallet. I fired up Multibit classic and tried to send the funds to a new wallet. Unfortunately, my password wouldn't work. Damn.

But! I found this script on multibit's support forums. https://multibit.org/help/v0.5/help_lostOrForgottenPassword.html

#!/bin/bash
echo Usage: apply-guesses.sh [password CSV] [key file] 
echo Password file: $1
echo Key file: $2
for password in $( awk -F , -v OFS=' ' '{print $3}' $1 ); do
   echo ------
   echo Attempting: $password...
   openssl enc -d -p -aes-256-cbc -a -in $2 -out recovered.key -pass pass:$password
   if [ $? -eq 0 ];
     then 
       echo "Success!";
       break;
     else 
       echo "Failed";
   fi
   echo ------
done

I ran the script using a csv of all my old bitcoin passwords and I got a success!

It returned this: (I changed all the numbers)

Attempting: password123
salt = 9823498243829374
key = 98237890238420938429830394850394
iv = 98743259384793847593844
Success!

But when I tried that password it still said it was incorrect. :(

But! it also created a file called recovered.key. I opened up the file and it was a bunch of badly encoded gibberish symbols like this: '¦ÀÌÁïûê¿^½”ß/øZÄÑQÛ,i¹´$'

I read somewhere that multibit keys are base 58 encoded so I encoded the recovered.key base 58 style and it became much more legible. Now I have a string of letters and numbers that's 611 characters long and starts with a '3'. Is this my private key?

I've been trying to import it into a new wallet in MultiBit classic, but no luck so far. I exported a private key from a new empty wallet and it looks like this: (I changed the key for this post)

# KEEP YOUR PRIVATE KEYS SAFE !
# Anyone who can read this file can spend your bitcoin.
#
# Format:
#   <Base58 encoded private key>[<whitespace>[<key createdAt>]]
#
#   The Base58 encoded private keys are the same format as
#   produced by the Satoshi client/ sipa dumpprivkey utility.
#
#   Key createdAt is in UTC format as specified by ISO 8601
#   e.g: 2011-12-31T16:42:00Z . The century, 'T' and 'Z' are mandatory
#
L1paCgWAYm2wzRfznmcoy5pbskdhShRVneAzBeuwaj244s7fr9nE 2017-09-04T21:54:32Z
# End of private keys

I swapped out the key in that wallet with my base58 recovered key, but it was a lot longer than this, and when I tried to import it it told me "Could not understand address in import file"

So... I have a really long string that I think is my private key, but I don't think it's in the right format. Also I might just be an idiot. Can anyone help me out?

Answer 1

This is a failed decryption

Unfortunately, openssl can sometimes respond with a zero even when the result is a failed decrypt due to padding and it appears that this is what has happened here.

I have more passwords to try...

I'd suggest modifying the script to avoid the break; after success. This will ensure that every one is tried. You can then go over the output and try the alternatives manually until you see an output that matches the # KEEP YOUR PRIVATE KEYS SAFE ! line which is the true representation of a successful decryption.

None of them worked...

If you are unable to unlock the wallet with the password then there are two possibilities:

1. You have the wrong password - more common that you'd think even when people swear blind that they're typing it correctly
2. The wallet/key file has become corrupted - very rare but exposes the fragility of encrypted files containing random private keys

Data does not exist unless it is in two places - ideally a local backup and a remote one. Even then files get corrupted just through hardware issues.

It was for the above reasons, and others, that the MultiBit development team strongly urged people for years to upgrade to MultiBit HD and the associated seed phrase which mitigates this situation entirely. Further, when creating keys and writing them out, MultiBit Classic checks that the data can be successfully read back in using the offered password.

What has happened?

In general when a file is AES encrypted there is a header section containing encryption specific data (key, salt, initialisation vector etc) then comes the main body of data. A corruption in the header section is a very serious problem as it renders decryption of the entire body almost impossible. A corruption in the body section allows for the wallet to be decrypted successfully but it could contain erroneous data.

What can I do?

Your first response should be to use reputable file recovery software. This will hopefully uncover early versions of wallet/key file backups and may undo the corruption through repair operations.

The quickest way to check the recovered files is to use OpenSSL as follows:

openssl enc -d -p -aes-256-cbc -a -in <ciphertext file> -out <plaintext file> -pass pass:<password>

The plaintext file should contain the text # KEEP YOUR PRIVATE KEYS SAFE ! if it has decrypted correctly (as shown in the question).

Next, find a wallet/exchange that accepts private keys and sweep the recovered bitcoins into a hardware wallet protected by a seed phrase - such as Trezor.

That didn't work

If all you have is a damaged file your last hope is to try to work out how the file has been corrupted. If it is in the header section where the key, initialisation vector, salt etc are stored then that's bad news. It's going to take a lot of work to rebuild those.

If it is later then you could get a partial decrypt but have incomplete private keys. Bitcoin does have reasonable checksums so you could use a key recovery script to try various combinations until one gives a working checksum. You can then look up the associated address of the public key and check for your funds.

In either of the above cases of corruption you will need to be a very accomplished coder to successfully rebuild the files. You might want to consider sending it to a specialist service.