Request the password from the user at startup and store the key in memory for all new key encryption. Each ekey in the wallet is decrypted and the privkey derived and checked against the stored pubkey to ensure the password is correct.
Thanks to jgarzik for the original patch and sipa for all his input.
Forum thread: http://www.bitcoin.org/smf/index.php?topic=7405
I see you took into consideration the issue of the password/key being swapped out but didn't actually write any code to prevent it. You should use mlock (unix) or VirtualLock (windows) to prevent memory from being swapped (the correct way of doing this is: allocate, mlock/VirtualLock, use the memory, when done overwrite it (random data is better than 0s), deallocate). Note: this still won't protect from other processes peeking at your memory, at least on windows.
Yea the whole ramdump to see password/key is pretty much impossible to prevent no matter what you do, so I'm really not going to try to fight it. Though, I'm planning to add more security to the encryption later, but having it now really isn't worth it for several reasons (see the original forum thread by jgarzik linked by the one about this pull).
As a side note, preventing any kind of key leakage is pretty much impossible in C++ when the user is entering the key in wx. If nothing else, the current value of the password dialog might end up in swap. I'll try to add a bunch of memlock's and memset/fills tomorrow but I don't think its possible for it to be 100%.
I guess so, unless we also patch wx in the process.
Now with more mlock(). Note I made a conscious decision here that I only bother to keep the actual password entered by the user out of memory/swap as much as possible, not the derived key or the private keys themselves. I have a separate branch which encrypts private keys in memory (much easier than not loading until needed in the current architecture) but still keeps the key to decrypt them in memory. Hopefully someone has the time to patch bitcoin to be a bit more careful about when it generates private keys and make it possible for password entry only at decrypt-time.
Note that any password longer than 100 characters will only have the first 100 mlock()d, but if you can't derive the key without all of the password, so I'm not concerned.
maybe adding some comments about this might help (eventually also mentioning that currently there's no way to stop another process from peeking and that we don't deal with hibernate-to-disk)
Request the password from the user at startup and store the key in memory for all new key encryption.
Each ekey in the wallet is decrypted and the privkey derived and checked against the stored pubkey
to ensure the password is correct.
Thanks to jgarzik for the original patch and sipa for all his input.
Now with more comments to clarify the purpose of mlock()s and such.
Now the question: I have a WIP branch which decrypts private keys only at spend-time (or it will in a couple days). Still a couple things to tighten down, but the question is which would rather be seen in bitcoin?
https://github.com/TheBlueMatt/bitcoin/tree/encprivkeys
well, keeping the keys encrypted in ram as a method to prevent other processes from reading it is pretty useless unless we manage to lock out all other processes from accessing our memory. reasking the password at spending-time is a good opt-in setting, but doesn't require keeping the keys encrypted in ram. so If I had to choose I'd definitely say wallet encryption over privkey encryption in ram. it would probably make more sense to have an hardware token (something like one of these http://www.hacker10.com/tag/hardware-security-token/ ) storing the privkey and doing the actual signing (so that the privkey never leaves it).
Superseded by #232 closed.