Topic: Wallet encryption issue - page 2. (Read 9664 times)

And the power goes out...

The one for windows is called sdelete. I remember reading somewhere that this utility wasn't possible to do identically in linux because of the file system for some reason.

well you could:
it will consume all free space on your root fs.

I seem to remember seeing some software at one point that securely overwrites all empty space in a filesystem. That was for Windows and I no longer even remember the name of the program. Something like that would be ideal to suggest to people who wish to secure their hard drives.

Would anyone happen to know the names of programs that can do this?

then delete the wallet file after putting back back keys from memory.

for unencrypted keys on freespace on disks:
DO NOT TRY THIS AT HOME.

I think a better method is to load all keys in to memory, flag all existing keys as "potentially insecure", create new set of keys and transfer all balances to new set of keys.  Then encrypt all keys.

Granted you still run the risk of receiving money on an old "insecure" key but your current balances are secure and the client could ensure it never re-used one of those old addresses again.

That will of course leave behind unencrypted copies of the keys in the unallocated space on the disk - not to mention the risk of data loss if Bitcoin or the computer crashes at the wrong moment - but it might be better than nothing.

fix:
load all keys in to memory.
delete wallet file.
make new encrypted wallet.
put back keys from memory.

I seem to recall that this was a known issue at the time wallet encryption was first implemented - was there meant to be something that fixed it since then?

This is a 0.4.0 issue.  Gavin was trying to release 0.5 in the immediate future, but I think he wants to hold it up until we find a fix for this problem.  We should get this fixed ASAP.

When I read this, I thought it was a report about the encryption in the existing 0.4 client. With Gavin's comment that it's holding up 0.5, it makes me unsure what version(s) this may be issue for.

Has anyone verified this?  I don't want to stop any shows unless someone else can confirm it.

BTW, I am on Ubuntu 10.04, 64-bit, if that matters...

Discussing how to fix this in IRC now.

This IS a show-stopper issue for the 0.5 release.

If that is true then the implementation is "borked".  Nothing in client docs indicate that limitation.  Users should at least be warned, even better would be for the client to recommend a transfer of all balances to a "new" address.

This is where casascius' recommendation for "sweepprivkey" becomes extremely useful.  

If you move all your coins out of the old keys and only use new keys (created after encrypting the wallet), there should be no problem.

- Joel

Wow. That is a problem. So we still need to encrypt our wallet file, even if it is encrypted by the client?

2012 Update:  It's now been a few months since this event, so I think it's safe to describe, for the record, what actually happened.  The Bitcoin wallet file is managed by BSDDB, which is a database engine.  Presumably, a database engine was used, in order to ensure ACID transactions (atomicity, consistency, isolation, durability), which makes sure that the database won't be corrupted by inconveniently-timed power outtages, etc.  Most importantly, it should protect your private keys from ever getting corrupted.

The problem with a database manager, though, is that it does its own thing with the file storage.  It's a black box in terms of its behavior when you tell it to "delete" something.  You'd hope it would actually remove the data, or at least blank it out, but that's not necessarily true.  In the case of BSDDB, when Satoshi client says "delete this key and replace it with the encrypted key" it seems to not actually do that.  Instead, it simply marks the entry deleted, and then appends the new data to the end of the file.  It doesn't even overwrite the original data.  

From the user perspective, this is completely transparent, because the user must ask the BSDDB interface for the data, and BSDDB reports that it's gone, since the pointer to the data was discarded.  But, it's still in the binary file!

Before wallet encryption, I had written a pure-binary key-extractor script, to pull my private keys out of the wallet file (it was an elaborate search using the ECDSA library to find public-keys and find the associated private-key nearby).  After Bitcoin 0.4.0 was released with wallet encryption, I re-ran my script for fun.  To my surprise, it found 36 of 112 private keys!  Whoops!

I wasn't too involved in the fix for the problem, since I have no experience with BSDDB.  But the solution had to do with convincing the database to actually remove/overwrite the data, and allow for wallets to be "born" encrypted to avoid any risk of it happening again.   I don't know the gory details though, you'd have to ask the devs for specific details about how they fixed it.




Original Post:
I think I might've found a bug in the wallet encryption.

Edit: This problem has been fixed in the client version 0.5.0.  Please see the release notes for information on fixing your wallet.   The most important information is: