LearnBitcoin

Bitcoin Dev Archive 2011

Wallet encryption migration

3 messages, 15 to 17 Jul 2011. Started by Luke Dashjr.

Luke Dashjr, Arthur Britto, Greg Maxwell

Permalink Original thread on gnusha.org

Luke Dashjr permalink original
Just wanted to get these suggestions out here:
1. Write over the old, unencrypted wallet.dat a couple of times with pseudo-
   random data in an attempt to secure-delete it.
2. Mark all the keys imported from an unencrypted file (wallet or otherwise)
   as "potentially compromised" and never use them for new addresses
   (basically, don't use the old keypool for getnewaddress, change, and such).
Arthur Britto in reply to Luke Dashjr permalink original

On Thu, Jul 14, 2011 at 7:50 PM, Luke-Jr <luke@dashjr•org> wrote:

Quoted text (5 lines)
> Just wanted to get these suggestions out here:
> 1. Write over the old, unencrypted wallet.dat a couple of times with
> pseudo-
>   random data in an attempt to secure-delete it.
>

Writing zeros just once should be sufficient: http://cmrr.ucsd.edu/people/Hughes/DataSanitizationTutorial.pdf

-Arthur

Greg Maxwell in reply to Luke Dashjr permalink original

On Thu, Jul 14, 2011 at 10:50 PM, Luke-Jr <luke@dashjr•org> wrote:

Quoted text (6 lines)
> Just wanted to get these suggestions out here:
> 1. Write over the old, unencrypted wallet.dat a couple of times with pseudo-
>   random data in an attempt to secure-delete it.
> 2. Mark all the keys imported from an unencrypted file (wallet or otherwise)
>   as "potentially compromised" and never use them for new addresses
>   (basically, don't use the old keypool for getnewaddress, change, and such).

On Sat, Jul 16, 2011 at 6:38 PM, Arthur Britto <ahbritto@gmail•com> wrote:

Quoted text (1 line)
> Writing zeros just once should be sufficient:

On many (most?) modern Unix file systems writing zeros just once is not sufficient because the data won't be written in place, but multiple writes aren't any better.

Moving the keypool addresses aside so they won't be used sounds like a good idea.

The lamest thing is that there is no way for wallet to be born-encrypted. So the only way to prevent a leak is to build the wallet initially on a ramdisk or the like, then move it over after encrypting it.

At least luke-jr's (2) would make the key leak on a new wallet inconsequential— since all keys in it are keypool keys at that point. So I really think it ought to be done.