<blockquote>
<p><strong>Does anyone know the correct method of decrypting this?</strong></p>
</blockquote>
<p>It doesn't seem to be encrypted. The comments at the start of the file don't mention any form of encryption. It only mentions a common form of encoding - Base58. Encoding is not encryption so no decryption is needed.</p>
<blockquote>
<blockquote>
<p><code>#   The</code> <strong><code>Base58</code></strong> <code>encoded private keys are the same format as</code><br />
<code>#   produced by the Satoshi client/ sipa</code> <strong><code>dumpprivkey</code></strong> <code>utility.</code></p>
</blockquote>
</blockquote>
<p>That Base58 key ought to be able to be imported into several different modern wallet programs.</p>
<p>See</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/36876/13866">Private keys importing in format got by dumpprivkey</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/52951/13866">How to get the private key in hex from the output of dumpprivkey</a></li>
<li><a href="https://btcinformation.org/en/developer-reference#dumpprivkey" rel="nofollow noreferrer">https://btcinformation.org/en/developer-reference#dumpprivkey</a></li>
</ul>
<hr />
<p>Addendum 2024</p>
<blockquote>
<p><strong>it's not accepted when I copy and paste [...] Guessing wrong format</strong></p>
</blockquote>
<p>If we assume the binary private-key was encrypted and then converted to Base58, it should be possible to reverse that process.</p>
<p>According to <a href="https://github.com/Multibit-Legacy/multibit/blob/master/src/main/java/org/multibit/crypto/KeyCrypterOpenSSL.java" rel="nofollow noreferrer">some Multibit related source code</a></p>
<pre><code> * If you encrypt a string with this class you can decrypt it with the OpenSSL
 * command: openssl enc -d -aes-256-cbc -a -in cipher.txt -out plain.txt -pass
 * pass:aTestPassword
 * 
 * where: cipher.txt = file containing the cipher text plain.txt - where you
 * want the plaintext to be saved
 * 
 * substitute your password for &quot;aTestPassword&quot; or remove the &quot;-pass&quot; parameter
 * to be prompted.
 * 
</code></pre>
<p>So I would try that <code>aes</code> command on two versions of the private key data from the wallet file:</p>
<ul>
<li>As is. Omitting comments, trailing blanks and date etc</li>
<li>Same but converted to binary from Base58 by using base58decode.</li>
</ul>
<p>I'd convert the result to Base58 encoding before attempting import, depending on what the documentation of the import tools tell you about the format they expect. It might be necessary to convert to WIF for example.</p>
<p>However, I've no idea if that source code corresponds to the Multibit classic used and I havent read the rest of the code to find out how that code is used (if at all) when reading the wallet data file.</p>

CC BY-SA 4.0
2024-04-07T14:48:49.310Z
Unfortunately it's not accepted when I copy and paste the key directly into a private key import such as electrum. Guessing wrong format or too few characters for a private key.
HippoDuck
CC BY-SA 4.0
2024-04-07T15:22:31.943Z
@HippoDuck: see addendum.
RedGrittyBrick
CC BY-SA 4.0
2021-03-30T15:15:15.397Z
2024-04-07T15:28:16.610Z
2024-04-07T15:28:16.610Z
RedGrittyBrick
<p>If the priv key starts with U2 and ends with = its most probably an md5 encryption.</p>
<p>Your password seems wrong, so you would need something like btcrecover that would jog through irerations.</p>
<p>You can find it on github here
<a href="https://github.com/gurnec/btcrecover" rel="nofollow noreferrer">https://github.com/gurnec/btcrecover</a></p>
<p>Good luck
/KX</p>

CC BY-SA 4.0
2023-05-15T16:11:28.277Z
I'm positive of the password though, long story but I remember the moment I set it up and the only password I used at the time etc. I will take a look at the GitHub repo. Thanks.
HippoDuck
CC BY-SA 4.0
2024-04-01T11:01:56.067Z
Did you solve your problem? If you got the string from the first image and the string starts with 5 or L then you can download electeum light wallet and import the private key.
KeychainX
CC BY-SA 4.0
2024-04-07T14:27:30.963Z
No, I was unable to get btcrecover to work. `ModuleNotFoundError: No module named 'cPickle'` Even on Python 2.7. Seems broken.
HippoDuck
CC BY-SA 4.0
2024-04-07T15:23:26.390Z
Will have to shelve the idea for another year frustratingly. I know it was about £100/£150 back in 2011/2012. No idea what it would be now.
HippoDuck
CC BY-SA 4.0
2023-05-14T15:12:34.013Z
2023-05-14T15:12:34.013Z
KeychainX
<p>I think the issue comes from password change inside the wallet on user's side. Multibit wallet has password change issues and many users posted this issue.</p>
<p>When you choose your password through Multibit’s user interface, the software passes it as an argument to the PKCS5PasswordToBytes method, which is part of the Spongy Castle library. This method accepts the password as a char array and outputs it as a byte array. It is later used to either encrypt or decrypt a .key file. Below, here’s how the method is implemented in the PBEParametersGenerator.java file. Can you spot the bug?</p>
<p>public static byte[] PKCS5PasswordToBytes(
char[]  password)
{
byte[]  bytes = new byte[password.length];</p>
<pre><code>    for (int i = 0; i != bytes.length; i++)
    {
        bytes[i] = (byte)password[i];
     }

   return bytes;
}
</code></pre>
<p>In Java, the char type is made up of 2 bytes; however, the code above assumes that a char is made up of only one byte! Thus, for each char processed in the loop, the low-order byte is kept while the high-order byte is discarded. Under the right circumstances, this can become an issue.</p>
<p>Since Java relies on the UTF-16 BE charset, Multibit encodes the password as 20 AC when it is entered in the user interface. When it is converted through the PKCS5PasswordToBytes method, the high-order byte (20) is dropped whereas the low-order byte (AC) is kept. Unlike with our previous example, AC is not the proper encoding for our password in any of the charsets above. As such, a password cracker may fail to decrypt the .key file even with the correct password. What are your options? If you haven’t done so already, you should try to unlock your wallet through Multibit Classic directly. Unfortunately, this approach quickly becomes impractical if you are unsure of your password and must type in every guess. In such a case, you will need a password cracker. You can avoid the bug described in this article by using the password cracker on a .wallet file instead of a .key file. While this approach beats typing in every guess, it scales terribly as the .wallet file has much better protection against password crackers than the .key file. Moreover, some of these tools have their own set of character encoding issues you should be aware of. If you use the password cracker on a .key file, they are multiple workarounds for character encoding issues, but they should be evaluated on a case-by-case basis and it is outside the scope of this article. I encourage you to keep doing your research or to contact me.</p>

CC BY-SA 4.0
2024-07-23T14:50:28.807Z
@HippoDuck, you can see my github and repos as reference.
Sweethappydream
CC BY-SA 4.0
2024-07-22T14:36:31.093Z
2024-07-22T14:36:31.093Z
Sweethappydream
<p>In your case you have a few options:</p>
<ol>
<li><strong>Using MultiBit Classic:</strong> Since MultiBitHD doesn't support Classic wallets, you might want to find a MultiBit Classic executable. Install it in a secure, offline environment to avoid any potential security risks. Open your wallet with the correct password and use the &quot;Export&quot; feature to extract your keys.</li>
<li><strong>Handling a .key File with plaintext:</strong>
Your first .key file contains plaintext and the encrypted private key. You should remove everything except the encrypted private key (U2FsdG...snQhpZ6) and attempt to decrypt it again. If there are multiple keys, repeat this process for each one.</li>
<li><strong>Dealing with the Multibit Protobuf .key File:</strong>
The second .key file you have uses the Multibit protobuf format. You can decrypt this using <a href="https://btcrecover.readthedocs.io/en/latest/" rel="nofollow noreferrer">btcrecover</a> with the following command:</li>
</ol>
<pre><code>python btcrecover.py --wallet ./btcrecover/test/test-wallets/multibit-wallet.key --correct-wallet-password [YOUR WALLET PASSWORD] --dump-privkeys multibit-wallet.key.privkeys.txt
</code></pre>
<p>After extracting the keys, you can import them into a different wallet like <a href="https://electrum.org/" rel="nofollow noreferrer">Electrum</a>.</p>

CC BY-SA 4.0
2023-11-25T14:59:32.383Z
2023-11-25T14:59:32.383Z
ReWallet
<p>I have a wallet file from 2011 back when I used to play around with Bitcoin.</p>
<p>I used an old version of Multibit which has since long been unavailable.</p>
<p>My wallet looks like this:</p>
<pre><code># KEEP YOUR PRIVATE KEYS SAFE !
# Anyone who can read this file can spend your bitcoin.
#
# Format:
#   &lt;Base58 encoded private key&gt;[&lt;whitespace&gt;[&lt;key createdAt&gt;]]
#
#   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
#
U2FsdGVXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsnQhpZ6
 2013-10-30T20:52:01Z
# End of private keys
</code></pre>
<p>I managed to get a version of Multibit HD from the web archive but this doesn't support this wallet.</p>
<p>I also tried using OpenSSL with the following command:</p>
<pre><code>openssl enc -d -p -aes-256-cbc -md md5 -a -in C:\key\wallet.key.txt -out c:\key\wallet-decrypted.key.txt
</code></pre>
<p>This output a file which wasn't correct and gave a <code>bad decrypt</code> error. I know the password for this file.</p>
<p>Does anyone know the correct method of decrypting this?</p>
<p>UPDATE: While I'm at it, I found a whole bunch more .key files. This one has a different format:</p>
<pre><code>org.bitcoin.productionm!œ;€ò=°´zXXXXXXXXXXXXXXXXXÌñ9,o( 2D
ä¢¦]5+¡XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE}Û@nŸé(2

ÐáXXXXR#
org.multibit.walletProtect.2 ZYour wallet description` 
</code></pre>

<wallet-recovery><multibit>
Recovering an old Multibit wallet file (76 characters long)
HippoDuck
# Recovering an old Multibit wallet file (76 characters long)

(Asked by: username_0 on 2021-03-29)

I have a wallet file from 2011 back when I used to play around with Bitcoin.

I used an old version of Multibit which has since long been unavailable.

My wallet looks like this:

```
# 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
#
U2FsdGVXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsnQhpZ6
 2013-10-30T20:52:01Z
# End of private keys

```

I managed to get a version of Multibit HD from the web archive but this doesn't support this wallet.

I also tried using OpenSSL with the following command:

```
openssl enc -d -p -aes-256-cbc -md md5 -a -in C:\key\wallet.key.txt -out c:\key\wallet-decrypted.key.txt

```

This output a file which wasn't correct and gave a `bad decrypt` error. I know the password for this file.

Does anyone know the correct method of decrypting this?

UPDATE: While I'm at it, I found a whole bunch more .key files. This one has a different format:

```
org.bitcoin.productionm!œ;€ò=°´zXXXXXXXXXXXXXXXXXÌñ9,o( 2D
ä¢¦]5+¡XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE}Û@nŸé(2

ÐáXXXXR#
org.multibit.walletProtect.2 ZYour wallet description` 

```

**Tags:** wallet-recovery, multibit


---

## 4 answers

### Answer by username_1 on 2021-03-30. Score: 2

> **Does anyone know the correct method of decrypting this?**

It doesn't seem to be encrypted. The comments at the start of the file don't mention any form of encryption. It only mentions a common form of encoding - Base58. Encoding is not encryption so no decryption is needed.

> > `# The` **`Base58`** `encoded private keys are the same format as`  
> > `# produced by the Satoshi client/ sipa` **`dumpprivkey`** `utility.`

That Base58 key ought to be able to be imported into several different modern wallet programs.

See

* [Private keys importing in format got by dumpprivkey](https://bitcoin.stackexchange.com/q/36876/13866)
* [How to get the private key in hex from the output of dumpprivkey](https://bitcoin.stackexchange.com/q/52951/13866)
* <https://btcinformation.org/en/developer-reference#dumpprivkey>

---

Addendum 2024

> **it's not accepted when I copy and paste [...] Guessing wrong format**

If we assume the binary private-key was encrypted and then converted to Base58, it should be possible to reverse that process.

According to [some Multibit related source code](https://github.com/Multibit-Legacy/multibit/blob/master/src/main/java/org/multibit/crypto/KeyCrypterOpenSSL.java)

```
 * If you encrypt a string with this class you can decrypt it with the OpenSSL
 * command: openssl enc -d -aes-256-cbc -a -in cipher.txt -out plain.txt -pass
 * pass:aTestPassword
 * 
 * where: cipher.txt = file containing the cipher text plain.txt - where you
 * want the plaintext to be saved
 * 
 * substitute your password for "aTestPassword" or remove the "-pass" parameter
 * to be prompted.
 * 

```

So I would try that `aes` command on two versions of the private key data from the wallet file:

* As is. Omitting comments, trailing blanks and date etc
* Same but converted to binary from Base58 by using base58decode.

I'd convert the result to Base58 encoding before attempting import, depending on what the documentation of the import tools tell you about the format they expect. It might be necessary to convert to WIF for example.

However, I've no idea if that source code corresponds to the Multibit classic used and I havent read the rest of the code to find out how that code is used (if at all) when reading the wallet data file.

> **Comments:**
> **username_0**: Unfortunately it's not accepted when I copy and paste the key directly into a private key import such as electrum. Guessing wrong format or too few characters for a private key.  
> **username_1**: @username_0: see addendum.  

---

### Answer by username_2 on 2023-05-14. Score: 1

If the priv key starts with U2 and ends with = its most probably an md5 encryption.

Your password seems wrong, so you would need something like btcrecover that would jog through irerations.

You can find it on github here
<https://github.com/gurnec/btcrecover>

Good luck
/KX

> **Comments:**
> **username_0**: I'm positive of the password though, long story but I remember the moment I set it up and the only password I used at the time etc. I will take a look at the GitHub repo. Thanks.  
> **username_2**: Did you solve your problem? If you got the string from the first image and the string starts with 5 or L then you can download electeum light wallet and import the private key.  
> **username_0**: No, I was unable to get btcrecover to work. `ModuleNotFoundError: No module named 'cPickle'` Even on Python 2.7. Seems broken.  
> **username_0**: Will have to shelve the idea for another year frustratingly. I know it was about £100/£150 back in 2011/2012. No idea what it would be now.  

---

### Answer by username_3 on 2024-07-22. Score: 0

I think the issue comes from password change inside the wallet on user's side. Multibit wallet has password change issues and many users posted this issue.

When you choose your password through Multibit’s user interface, the software passes it as an argument to the PKCS5PasswordToBytes method, which is part of the Spongy Castle library. This method accepts the password as a char array and outputs it as a byte array. It is later used to either encrypt or decrypt a .key file. Below, here’s how the method is implemented in the PBEParametersGenerator.java file. Can you spot the bug?

public static byte[] PKCS5PasswordToBytes(
char[] password)
{
byte[] bytes = new byte[password.length];

```
    for (int i = 0; i != bytes.length; i++)
    {
        bytes[i] = (byte)password[i];
     }

   return bytes;
}

```

In Java, the char type is made up of 2 bytes; however, the code above assumes that a char is made up of only one byte! Thus, for each char processed in the loop, the low-order byte is kept while the high-order byte is discarded. Under the right circumstances, this can become an issue.

Since Java relies on the UTF-16 BE charset, Multibit encodes the password as 20 AC when it is entered in the user interface. When it is converted through the PKCS5PasswordToBytes method, the high-order byte (20) is dropped whereas the low-order byte (AC) is kept. Unlike with our previous example, AC is not the proper encoding for our password in any of the charsets above. As such, a password cracker may fail to decrypt the .key file even with the correct password. What are your options? If you haven’t done so already, you should try to unlock your wallet through Multibit Classic directly. Unfortunately, this approach quickly becomes impractical if you are unsure of your password and must type in every guess. In such a case, you will need a password cracker. You can avoid the bug described in this article by using the password cracker on a .wallet file instead of a .key file. While this approach beats typing in every guess, it scales terribly as the .wallet file has much better protection against password crackers than the .key file. Moreover, some of these tools have their own set of character encoding issues you should be aware of. If you use the password cracker on a .key file, they are multiple workarounds for character encoding issues, but they should be evaluated on a case-by-case basis and it is outside the scope of this article. I encourage you to keep doing your research or to contact me.

> **Comments:**
> **username_3**: @username_0, you can see my github and repos as reference.  

---

### Answer by username_4 on 2023-11-25. Score: -1

In your case you have a few options:

1. **Using MultiBit Classic:** Since MultiBitHD doesn't support Classic wallets, you might want to find a MultiBit Classic executable. Install it in a secure, offline environment to avoid any potential security risks. Open your wallet with the correct password and use the "Export" feature to extract your keys.
2. **Handling a .key File with plaintext:**
   Your first .key file contains plaintext and the encrypted private key. You should remove everything except the encrypted private key (U2FsdG...snQhpZ6) and attempt to decrypt it again. If there are multiple keys, repeat this process for each one.
3. **Dealing with the Multibit Protobuf .key File:**
   The second .key file you have uses the Multibit protobuf format. You can decrypt this using [btcrecover](https://btcrecover.readthedocs.io/en/latest/) with the following command:

```
python btcrecover.py --wallet ./btcrecover/test/test-wallets/multibit-wallet.key --correct-wallet-password [YOUR WALLET PASSWORD] --dump-privkeys multibit-wallet.key.privkeys.txt

```

After extracting the keys, you can import them into a different wallet like [Electrum](https://electrum.org/).


---

