Gavin Andresen (OP)
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 09:57:20 PM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
evoorhees
Legendary
Offline
Activity: 1008
Merit: 1023
Democracy is the original 51% attack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 10:09:43 PM |
|
Very much appreciate the notice, Gavin. Thank you!
|
|
|
|
coinjedi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 10:19:04 PM |
|
Thanks for the heads-up. We appreciate your hard work.
|
|
|
|
graingert
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 11:22:08 PM |
|
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
|
*Image Removed*
|
|
|
mndrix
Michael Hendricks
VIP
Sr. Member
Offline
Activity: 447
Merit: 258
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 11:29:48 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 11:37:42 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2011, 11:38:04 PM |
|
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
|
*Image Removed*
|
|
|
Gavin Andresen (OP)
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 12:00:42 AM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
graingert
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 12:02:50 AM |
|
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
|
*Image Removed*
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 12:06:42 AM |
|
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
Administrator
Legendary
Offline
Activity: 5306
Merit: 13296
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 12:08:40 AM |
|
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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
bitstarter
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 12:32:09 AM |
|
Thank you for this information! ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif)
|
|
|
|
MysteryMiner
Legendary
Offline
Activity: 1512
Merit: 1049
Death to enemies!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 02:12:05 AM |
|
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.
|
bc1q59y5jp2rrwgxuekc8kjk6s8k2es73uawprre4j
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 02:14:45 AM |
|
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
Legendary
Offline
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 02:24:02 AM |
|
Meanwhile, Zipping with encryption still works perfectly.....
|
|
|
|
MysteryMiner
Legendary
Offline
Activity: 1512
Merit: 1049
Death to enemies!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 02:26:21 AM |
|
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.
|
bc1q59y5jp2rrwgxuekc8kjk6s8k2es73uawprre4j
|
|
|
bitplane
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 04:10:26 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 04:16:30 AM |
|
"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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 06:08:57 AM |
|
"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
Legendary
Offline
Activity: 1500
Merit: 1022
I advocate the Zeitgeist Movement & Venus Project.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2011, 06:27:09 AM |
|
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?
|
|
|
|
|