Wallet encryption bug found (IMPORTANT!)

[Gavin Andresen]

A serious bug was been found in the "encrypt wallet" function of bitcoin versions 0.4 and 0.5: private keys may be left unencrypted in the wallet.dat file after encryption.

If your encrypted 0.4 wallet file is stolen, an attacker may be able to recover some or all of your private keys and steal some or all of your bitcoins.

The development team has been working on fixes for bitcoin versions 0.4 and 0.5, but it will take at least a few days to test them thoroughly. Until they are available, you should assume that your 'encrypted' wallets are as vulnerable as an unencrypted wallet, and follow all the best practices for keeping them safe (see here for a list).

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

[evoorhees]

Very much appreciate the notice, Gavin. Thank you!

[coinjedi]

Thanks for the heads-up. We appreciate your hard work.

[graingert]

This issue can be "worked around" by generating a new address and sending all bitcoin there.

You should also remember to change all existing static addresses left on the web

[mndrix]

constructive suggestions on how to improve the testing and release processes ... are welcome.

How was this particular bug discovered?  That might help us formulate strategies for catching similar problems going forward.

[P4man]

Just a wild idea; but Google and others give bounties for security bugs that are submitted. Perhaps we could set up a small fund, and pay anyone who finds critical bugs in beta versions?

[graingert]

constructive suggestions on how to improve the testing and release processes ... are welcome.

How was this particular bug discovered?  That might help us formulate strategies for catching similar problems going forward.

https://bitcointalk.org/index.php?topic=51474.0

[Gavin Andresen]

This issue can be "worked around" by generating a new address and sending all bitcoin there.

That's not quite right-- you need to exhaust all of the keys in your 'key pool' to be safe, so you'd have to ask for 101 new keys.

Part of the fix is marking all of the keys in the keypool as used.

[graingert]

This issue can be "worked around" by generating a new address and sending all bitcoin there.

That's not quite right-- you need to exhaust all of the keys in your 'key pool' to be safe, so you'd have to ask for 101 new keys.

Part of the fix is marking all of the keys in the keypool as used.

This fix should be back-ported to version 0.4.0

[Luke-Jr]

This issue can be "worked around" by generating a new address and sending all bitcoin there.

That's not quite right-- you need to exhaust all of the keys in your 'key pool' to be safe, so you'd have to ask for 101 new keys.

Part of the fix is marking all of the keys in the keypool as used.

This fix should be back-ported to version 0.4.0

It will be, for bitcoind at least. If someone wants to step up to maintain wxBitcoin, contact me (or join #bitcoin-stable on FreeNode).

[theymos]

Features seem to be considered stable way too quickly. I'd like a version scheme like this:
- Add new features to 0.5.
- At some point, stop adding new features to 0.5 and call that the "unstable" release. Start adding new features to 0.6.
- 0.4 remains the "stable" release for at least 6 months, and it is recommend that newbies use this version. The unstable version is also available in binary form and can be easily used.
- Once 0.5 has been unstable for 6+ months, call that one stable.
- As many past 0.x releases as possible continue to get bugfixes for people who like to use really stable software.

I'm still using 0.3.19, and it works fine with only a few modifications. I avoided several bugs by doing this.

Once this problem is fixed, it would be a good idea to issue an alert for users of affected versions. Maybe not many users are affected, but it seems irresponsible to not notify these users when they can be notified.

[bitstarter]

Thank you for this information!

[MysteryMiner]

No intention to offend somebody, but this is FAIL. How such thing is possible? My solution - change wallet.dat format. First bits - wallet! identification string, next bits - wallet format version, next bit - encrypted or not. Every next bit is encrypted similar to truecrypt volume, and have included checks for correctness of supplied password. The wallet.dat file is decrypted on-the-fly as it is acessed by bitcoin software. The only inconvinience is that the wallet password must be supplied every time when starting bitcoin client, not only when sending coins.

[Luke-Jr]

The only inconvinience is that the wallet password must be supplied every time when starting bitcoin client, not only when sending coins.

Which totally defeats the purpose of wallet encryption. If you're going to do it that way, you might as well just encrypt on backup only (which would be a very nice feature anyway...)

[Xenland]

Meanwhile, Zipping with encryption still works perfectly.....

[MysteryMiner]

The only inconvinience is that the wallet password must be supplied every time when starting bitcoin client, not only when sending coins.

Which totally defeats the purpose of wallet encryption. If you're going to do it that way, you might as well just encrypt on backup only (which would be a very nice feature anyway...)

The encryption of only private keys are no solution either. Just wait until victim sends the coins to someone, then recover the password using keylogger. It can only protect against trivial attacks such as grabbing the wallet.dat file right away. There is no real way of securing the wallet.dat file on compromised computer. But if I use encryption, I would like the whole wallet.dat to be encrypted, so even if shit hits the fan and my wallet.dat is leaked, all my adresses are not disclosed to attacker.

[bitplane]

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

I guess the opaqueness of the wallet data file prevents people from having a poke around and reading it.

Binary formats are efficient for the computer, but they aren't very transparent and actively discourage casual reading by curious users. If the wallet were in XML, JSON or some other text-based format then I guess this would have been immediately obvious to anyone with a text editor and a pair of eyes.

[fellowtraveler]

"Thanks for all your hard work!" is not good enough. IMO, You guys need to figure out an organized way to fund Gavin's work.  

When he says, "It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release...Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project..."

...That is developer-speak for, "I need better Q/A volunteers or I need funding to pay for them, and it's embarrassing that I even have to say this in the first place when I should be focused on my code right now."

Support your guy.

[Fluttershy]

"Doesn't actually do what it's supposed to" is an embarrassing bug. It might've even encouraged people to not bother putting their wallet in some kind of encryption.

[LightRider]

A serious bug was been found in the "encrypt wallet" function of bitcoin versions 0.4 and 0.5: private keys may be left unencrypted in the wallet.dat file after encryption.

If your encrypted 0.4 wallet file is stolen, an attacker may be able to recover some or all of your private keys and steal some or all of your bitcoins.

The development team has been working on fixes for bitcoin versions 0.4 and 0.5, but it will take at least a few days to test them thoroughly. Until they are available, you should assume that your 'encrypted' wallets are as vulnerable as an unencrypted wallet, and follow all the best practices for keeping them safe (see here for a list).

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

Would it be possible to leverage the ability of major community stake holders (Mt. Gox, Pool Operators) to incentivize or encourage activity on the testnet for new builds?