"Lost" password to BIP38 encrypted private key, encrypter may be faulty (Bippy)

Question

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. 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 :)

Answer 1

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 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 - all credits to fpgaminer

Answer 2

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 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.