<p>It turns out Bippy <em>does</em> have a bug in the encryption algorithm where it mixes up the public key compression flag. As pointed out, I posted this problem on <a href="https://www.reddit.com/r/Bitcoin/comments/7axbqk/lost_password_to_bip38_encrypted_private_key/" rel="nofollow noreferrer">reddit</a> as well, and a solution has been posted there:</p>

<blockquote>
  <p>Bippy is definitely doing something wrong.</p>
  
  <p><strong>Technical Explanation</strong></p>
  
  <p>BIP38 encrypted keys have 4 components (in the simplest case).</p>
  
  <p>The first two letters of the key, 6P, are a marker that say this is a BIP38 encrypted key.</p>
  
  <p>The next letter, Y in this case, specify some attributes of the key. In this case it says "This is a simple BIP38 key, and the public key should be compressed."</p>
  
  <p>The next couple letters (4 bytes in the hex representation) specify a "checksum". We'll get back to this.</p>
  
  <p>The rest of the key is the real meat of it. It's the encrypted private key. That's what we care most about.</p>
  
  <p>Now let's get back to that checksum. The checksum is 4 bytes derived from the Bitcoin address associated with the original private key. A big caveat here is that there are actually two Bitcoin addresses associate with a plain Bitcoin private key. One is based off the compressed public key, and the other the uncompressed public key.</p>
  
  <p>That's why BIP38 encrypted keys specify whether they are using the compressed or uncompressed address.</p>
  
  <p>In this case, Bippy spit out a Y which means it used the compressed address. In your screenshots it even says as much. BUT here's where the problem is.</p>
  
  <p>When we check the checksum Bippy spit out, it doesn't match with a compressed address. But if we use the uncompressed address, it matches! So Bippy says it's using the compressed address, but it's actually using the uncompressed address.</p>
  
  <p>So Bippy definitely has a bug where it's using the uncompressed address, but saying in the resulting BIP38 key that it used the compressed address.</p>
  
  <p>This isn't too big a deal. I'll discuss this after the non technical explaination.</p>
  
  <p><strong>Nontechnical Explanation</strong></p>
  
  <p>Bippy is encrypting correctly, but it's screwing up its encoding of the encrypted key. It's saying it used public key compression when actually it didn't. This isn't a huge deal.</p>
  
  <p><strong>Solution</strong></p>
  
  <p>So, the good news is that it looks like, other than that minor bug, Bippy is encrypted the important stuff correctly. It should be possible to take your "lost" Bippy key and recover the private key from it. Assuming your password is correct.</p>
  
  <p>I should be able hack up my script to take care of that for you. I'll to to work on that and get back to you. (I need to fold in some Base58 encoding/decoding into the script and make it a bit user friendly for ya ;) ). The code will be quite simple Python code, so you can do a cursory glance to be sure it doesn't do anything evil.</p>
</blockquote>

<p>A python recovery script has been supplied as well, available on <a href="https://github.com/fpgaminer/bippy-recover" rel="nofollow noreferrer">github</a> - all credits to <strong>fpgaminer</strong></p>

CC BY-SA 3.0
2017-11-07T19:48:17.160Z
2017-11-07T19:48:17.160Z
Pantalaimon
<p>If there is a bug in Bippy and it's generating incorrect encrypted private keys, that would make your unencrypted private key unrecoverable, unless the bug in Bippy was something as simple as changing the passphrase before putting it through the encryption algorithm. </p>

<p>I haven't been able to get Bippy to build on my machine so I haven't been able to test. But I used <a href="https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html#" rel="nofollow noreferrer">bitcoinpaperwallet.com</a> to test your above keys, and when I use the passphrase <code>testingOneTwo</code> to encrypt <code>5Ka1Bv4RpKayZygPhZbBcREejqeYwq2iSRzWPKsg49SPgVRTnpW</code>, the result is the encrypted private key of <code>6PRLKpRdHRsMJcjuMYoE4wpKYUZEX11oB9LejdU8JuDLxynpDZFZWMNkDv</code>. </p>

<p>I haven't been able to find anyone else running into this problem. I would suggest trying to decrypt your private key using another BIP38 tool such as the "Validate or Decrypt" section on bitcoinpaperwallet.com.</p>

<p>If that doesn't work, it could help if you really walked us through step by step (with screenshots) how you are both generating the encrypted private key and how you are decrypting it.</p>

CC BY-SA 3.0
2017-11-05T19:29:27.737Z
2017-11-05T19:29:27.737Z
Eric Allam
<p>Few years ago I encrypted my Bitcoin private key for cold storage with an offline app called Bippy. Recently I tried to access my wallet by decrypting the private key, but my password was rejected.</p>

<p>I've checked out this Bippy program again, and I'm beginning to suspect it's faulty somehow. It seems that private keys beginning with a '5' - encrypted with Bippy - won't decrypt with the same password. Other prefixes seem to work OK.</p>

<p>Now, this Bippy app is open-source and written in Python, and I got it from <a href="https://github.com/inuitwallet/bippy" rel="nofollow noreferrer">here</a>. I've tried, as a test, to encrypt the private key <strong>5Ka1Bv4RpKayZygPhZbBcREejqeYwq2iSRzWPKsg49SPgVRTnpW</strong> with password <strong>testingOneTwo</strong> (it's a fresh pk, no bitcoins there ;)). In Bippy this encrypts to <strong>6PYMN8WT4CW7xLYczLvYfXZCtQWND7XEesk32QbXujMgKhf2v5A2ZQANpL</strong>, however, using the above password fails to decrypt it to its original... I've tried several other '5'-private keys and passwords, and the same happens every time.</p>

<p>Luckily the program is open-source; sadly, the project seems abandoned a few years back and my knowledge of Python and encryption is not at a level good enough to pinpoint the bug at play here, and hoping for some help here :)</p>

CC BY-SA 3.0
2017-11-05T19:19:38.853Z
What did you use to try and decrypt the encrypted private key? Bippy?
Eric Allam
CC BY-SA 3.0
2017-11-05T20:35:21.150Z
It should be noted this was originally asked on [reddit](https://www.reddit.com/r/Bitcoin/comments/7axbqk/lost_password_to_bip38_encrypted_private_key/) and someone there even posted some code.
adam W
<private-key><recover-private-key><bip38>
"Lost" password to BIP38 encrypted private key, encrypter may be faulty (Bippy)
Pantalaimon
# "Lost" password to BIP38 encrypted private key, encrypter may be faulty (Bippy)

(Asked by: username_0 on 2017-11-05)

Few years ago I encrypted my Bitcoin private key for cold storage with an offline app called Bippy. Recently I tried to access my wallet by decrypting the private key, but my password was rejected.

I've checked out this Bippy program again, and I'm beginning to suspect it's faulty somehow. It seems that private keys beginning with a '5' - encrypted with Bippy - won't decrypt with the same password. Other prefixes seem to work OK.

Now, this Bippy app is open-source and written in Python, and I got it from [here](https://github.com/inuitwallet/bippy). I've tried, as a test, to encrypt the private key **5Ka1Bv4RpKayZygPhZbBcREejqeYwq2iSRzWPKsg49SPgVRTnpW** with password **testingOneTwo** (it's a fresh pk, no bitcoins there ;)). In Bippy this encrypts to **6PYMN8WT4CW7xLYczLvYfXZCtQWND7XEesk32QbXujMgKhf2v5A2ZQANpL**, however, using the above password fails to decrypt it to its original... I've tried several other '5'-private keys and passwords, and the same happens every time.

Luckily the program is open-source; sadly, the project seems abandoned a few years back and my knowledge of Python and encryption is not at a level good enough to pinpoint the bug at play here, and hoping for some help here :)

**Tags:** private-key, recover-private-key, bip38

> **Comments:**
> **username_1**: What did you use to try and decrypt the encrypted private key? Bippy?  
> **username_2**: It should be noted this was originally asked on [reddit](https://www.reddit.com/r/Bitcoin/comments/7axbqk/lost_password_to_bip38_encrypted_private_key/) and someone there even posted some code.  

---

## 2 answers

### Answer by username_0 on 2017-11-07. Score: 2 | Accepted answer

It turns out Bippy *does* have a bug in the encryption algorithm where it mixes up the public key compression flag. As pointed out, I posted this problem on [reddit](https://www.reddit.com/r/Bitcoin/comments/7axbqk/lost_password_to_bip38_encrypted_private_key/) as well, and a solution has been posted there:

> Bippy is definitely doing something wrong.
>
> **Technical Explanation**
>
> BIP38 encrypted keys have 4 components (in the simplest case).
>
> The first two letters of the key, 6P, are a marker that say this is a BIP38 encrypted key.
>
> The next letter, Y in this case, specify some attributes of the key. In this case it says "This is a simple BIP38 key, and the public key should be compressed."
>
> The next couple letters (4 bytes in the hex representation) specify a "checksum". We'll get back to this.
>
> The rest of the key is the real meat of it. It's the encrypted private key. That's what we care most about.
>
> Now let's get back to that checksum. The checksum is 4 bytes derived from the Bitcoin address associated with the original private key. A big caveat here is that there are actually two Bitcoin addresses associate with a plain Bitcoin private key. One is based off the compressed public key, and the other the uncompressed public key.
>
> That's why BIP38 encrypted keys specify whether they are using the compressed or uncompressed address.
>
> In this case, Bippy spit out a Y which means it used the compressed address. In your screenshots it even says as much. BUT here's where the problem is.
>
> When we check the checksum Bippy spit out, it doesn't match with a compressed address. But if we use the uncompressed address, it matches! So Bippy says it's using the compressed address, but it's actually using the uncompressed address.
>
> So Bippy definitely has a bug where it's using the uncompressed address, but saying in the resulting BIP38 key that it used the compressed address.
>
> This isn't too big a deal. I'll discuss this after the non technical explaination.
>
> **Nontechnical Explanation**
>
> Bippy is encrypting correctly, but it's screwing up its encoding of the encrypted key. It's saying it used public key compression when actually it didn't. This isn't a huge deal.
>
> **Solution**
>
> So, the good news is that it looks like, other than that minor bug, Bippy is encrypted the important stuff correctly. It should be possible to take your "lost" Bippy key and recover the private key from it. Assuming your password is correct.
>
> I should be able hack up my script to take care of that for you. I'll to to work on that and get back to you. (I need to fold in some Base58 encoding/decoding into the script and make it a bit user friendly for ya ;) ). The code will be quite simple Python code, so you can do a cursory glance to be sure it doesn't do anything evil.

A python recovery script has been supplied as well, available on [github](https://github.com/fpgaminer/bippy-recover) - all credits to **fpgaminer**


---

### Answer by username_1 on 2017-11-05. Score: 1

If there is a bug in Bippy and it's generating incorrect encrypted private keys, that would make your unencrypted private key unrecoverable, unless the bug in Bippy was something as simple as changing the passphrase before putting it through the encryption algorithm.

I haven't been able to get Bippy to build on my machine so I haven't been able to test. But I used [bitcoinpaperwallet.com](https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html#) to test your above keys, and when I use the passphrase `testingOneTwo` to encrypt `5Ka1Bv4RpKayZygPhZbBcREejqeYwq2iSRzWPKsg49SPgVRTnpW`, the result is the encrypted private key of `6PRLKpRdHRsMJcjuMYoE4wpKYUZEX11oB9LejdU8JuDLxynpDZFZWMNkDv`.

I haven't been able to find anyone else running into this problem. I would suggest trying to decrypt your private key using another BIP38 tool such as the "Validate or Decrypt" section on bitcoinpaperwallet.com.

If that doesn't work, it could help if you really walked us through step by step (with screenshots) how you are both generating the encrypted private key and how you are decrypting it.


---

