Secure Wallet Management, Best Practices

[Melbustus]

Ok, so I have a fairly common use-case. I own some bitcoin (for spending and for long-term holding). I currently hold my non-immediate-spend btc in various backed-up and encrypted wallets for which only I know the decryption-key/password. I do not have the password written down anywhere, and I want to keep it that way. I also do not want to print out a clear-text private key.

I do need other people to potentially have access to my bitcoin if something happens to me. I will probably have my wife memorize my password.

I know the typical solution is a paper-wallet, but I hate the idea of this being cleartext anywhere. Yes, I know this amounts to a brainwallet, but I consider the absolute lack of physical theft being a problem to be a huge plus.

So what do people typically do?

[interlagos]

Store your password-protected wallet in one place (few places) and the password itself written on paper in another place (few places).
Make sure that those two sets of places don't intersect and hard to link together. That eliminates the risk of physical theft.

[CIYAM]

Another approach to consider would be to print out a private key as a QR code then slice it into two (or more) pieces.

You can then have them held separately by family member(s) to be combined when needed.

[Stephen Gornick]

So what do people typically do?

Coming soon to BitAddress.org, encrypted paper wallets:

So the encrypted paper wallet(s) go to family members.  DeadMansSwitch gets the decryption key, as does the trustee.  From another thread:

I changed the colour to blue for encrypted paper wallets to provide distinction between encrypted/unencrypted paper wallets - a version in the original yellow is included in case you really like yellow, just delete 'note_encrypted.png' and rename 'note_yellow.png' in its place.

This solution (encrypted paper wallets) robably isn't ready for prime time, but give it a few weeks and that will probably become a very good method for offline / long term savings that is secure.

[hazek]

Cool!

[Melbustus]

Another approach to consider would be to print out a private key as a QR code then slice it into two (or more) pieces.

You can then have them held separately by family member(s) to be combined when needed.

I like this idea... Might do this in the short term.

[Melbustus]

So what do people typically do?

Coming soon to BitAddress.org, encrypted paper wallets:

So the encrypted paper wallet(s) go to family members.  DeadMansSwitch gets the decryption key, as does the trustee.  From another thread:

I changed the colour to blue for encrypted paper wallets to provide distinction between encrypted/unencrypted paper wallets - a version in the original yellow is included in case you really like yellow, just delete 'note_encrypted.png' and rename 'note_yellow.png' in its place.

This solution (encrypted paper wallets) robably isn't ready for prime time, but give it a few weeks and that will probably become a very good method for offline / long term savings that is secure.

Nice... Will check this out when it's ready!

[casascius]

I would think it already works - the improvements it needs are mainly performance (some browsers will crash) but it should work fine (albeit slowly) under Chrome.  It's the encryption process that is deliberately difficult and slow.  And also, until it becomes more popular, there aren't very many places to redeem/import the wallets.  I am hoping more sites offer built-in decryption, but until then, you'll have to use a decryption utility yourself to get the unencrypted private key.  The "Wallet Details" tab can do decryption.

My Windows utility prints and decrypts encrypted paper wallets and...it works.  Without being too slow, since it's compiled code.  Same BIP38 encryption.

Just for fun, I tried creating an encrypted paper wallet using this https://raw.github.com/Zeilap/bitaddress.org/master/bitaddress.org.html

And decrypted it with my Windows utility just now, and it decrypted correctly and arrived at the same private key as using the page itself to decrypt...

A good storage strategy is to make 2 copies of the encrypted wallet and put them in 2 safe places (e.g. safety deposit box), and then either put the password in 2 separate safe places, or tell 2 people the password, in addition to remembering it yourself.  Recovery will require access to the paper as well as access to the passphrase, all while being immune to the loss of any one thing (e.g. bank fire, someone dies).

(For those who don't know, I am the one who came up with the BIP38 encryption/decryption scheme)

[Melbustus]

I would think it already works - the improvements it needs are mainly performance (some browsers will crash) but it should work fine (albeit slowly) under Chrome.  It's the encryption process that is deliberately difficult and slow.  And also, until it becomes more popular, there aren't very many places to redeem/import the wallets.  I am hoping more sites offer built-in decryption, but until then, you'll have to use a decryption utility yourself to get the unencrypted private key.  The "Wallet Details" tab can do decryption.

My Windows utility prints and decrypts encrypted paper wallets and...it works.  Without being too slow, since it's compiled code.  Same BIP38 encryption.

Just for fun, I tried creating an encrypted paper wallet using this https://raw.github.com/Zeilap/bitaddress.org/master/bitaddress.org.html

And decrypted it with my Windows utility just now, and it decrypted correctly and arrived at the same private key as using the page itself to decrypt...

A good storage strategy is to make 2 copies of the encrypted wallet and put them in 2 safe places (e.g. safety deposit box), and then either put the password in 2 separate safe places, or tell 2 people the password, in addition to remembering it yourself.  Recovery will require access to the paper as well as access to the passphrase, all while being immune to the loss of any one thing (e.g. bank fire, someone dies).

(For those who don't know, I am the one who came up with the BIP38 encryption/decryption scheme)

Good stuff. Thanks.

Another ideal requirement for me is that the encrypted paper key printout contains sufficient information to execute the decryption process for someone who knows the key. Is this possible? How big is the source for the core of the decryption process? If these are simply fully documented and well-known algorithms, a reference to them makes sense in my opinion, on the physical paper. This is all protecting against the case where, years from now, someone other than me needs to use the key because I can't.

Additionally, I would like to be able to trust storing encrypted wallets in the cloud. The general advice seems to be to only store the encrypted wallets in "safe" places. If we trust the encryption in the first place, why do we not trust storing such an encrypted wallet in the cloud (emailing to one's gmail account, for example)?

[bullioner]

I use btcspw(1) to create split paper wallets.  I'm on Debian and use the packages from http://6-0.debian.packages.oxix.org/  (the package containing btcspw(1) is called btc-perl, and it pulls in various dependencies) but the source is at https://github.com/tomgjones/btc-perl

Example to create 6 address/key pairs, with the keys split on to 5 different sheets so that any 3 can be combined to recover the key:

    

Code:

$ btcspw 6 3 5 > my_split_wallet.html

I do this on a disconnected laptop which has encrypted swap, using a tmpfs for the working files and browser cache, and connect directly to a usb printer to print out the result after opening the html file in a browser.

The sheets contain enough context that someone competent should know what to do with them.

Manpage doesn't seem to be rendered on the web, so pasting it here:

Code:

NAME
       btcspw - Make a new bitcoin paper wallet with split keys.

SYNOPSIS
           btcspw [OPTIONS] [X] [M] [N]

           OPTIONS

           -n,--name=NAME       Give wallet name, to appear in page titles.

DESCRIPTION
       btcspw generates a paper Bitcoin wallet, split across multiple sheets
       using Shamir's Secret Sharing Scheme, in HTML format, and writes it to
       standard output.

       The output format includes the address and shares of the WIF-format
       private key, along with QR codes for each.  Each share of the wallet is
       labelled with a title, and each private key share is labelled with its
       share number, the total number of shares for this wallet, and the
       threshold of shares required to reconstruct the private key.

       X is the number of keys and addresses to generate.  Defaults to 1.

       M and N are the number of parts needed to reconstruct the private keys,
       and the total number of parts to split the keys into, respectively.
       Think "M of N secret sharing".

       M defaults to 2.  N defaults to N + 1.  The minimum values for M and N
       are both 2, and it doesn't make sense to have M greater than N.

       The current implementation will tend to emit warnings such as

           WARNING: couldn't get memory lock (ENOMEM, try to adjust RLIMIT_MEMLOCK!).

       due to its use of ssss(1).

SECURITY CONSIDERATIONS
       This section describes some security considerations that are specific
       to this program, and doesn't give general advice about managing Bitcoin
       paper wallets or cryptographic secret sharing.

       Generated private keys and addresses should always be verified using an
       independent application before sending any money to the generated
       addresses.

       This program is intended to work well on a computer that's not on any
       networks.

       To avoid complete copies of the key information being created in non-
       volatile storage on the computer where btcspw is run, a couple of tips
       can be followed.  Firstly, ensure any swap space is encrypted and is
       reinitialised every boot with a random key.  Secondly, create the HTML
       file in a tmpfs or a similar in-memory filesystem.  Thirdly, render the
       file in a browser using a uid that doesn't have write access to its own
       home directory, or to anywhere else where the browser might attempt to
       store cache or other state.

       Remember to take the security of the printer into account.

SEE ALSO
       btcgenkey(1), btcaddr(1)

       https://www.bitaddress.org/

[cypherdoc]

Additionally, I would like to be able to trust storing encrypted wallets in the cloud. The general advice seems to be to only store the encrypted wallets in "safe" places. If we trust the encryption in the first place, why do we not trust storing such an encrypted wallet in the cloud (emailing to one's gmail account, for example)?

i don't think there is a good reason against this.  except that once retrieved, you should isolate the encrypted wallet to an offline, clean computer where you can decrypt safely.

[casascius]

Another ideal requirement for me is that the encrypted paper key printout contains sufficient information to execute the decryption process for someone who knows the key. Is this possible? How big is the source for the core of the decryption process? If these are simply fully documented and well-known algorithms, a reference to them makes sense in my opinion, on the physical paper. This is all protecting against the case where, years from now, someone other than me needs to use the key because I can't.

The process is BIP38 and is fully documented.  Simply Google BIP38 and you'll get links to the documentation and source code for multiple implementations in code.  It uses well-known primitives (scrypt, AES, SHA256), and chances are pretty good it'll stick around for a while.

Additionally, I would like to be able to trust storing encrypted wallets in the cloud. The general advice seems to be to only store the encrypted wallets in "safe" places. If we trust the encryption in the first place, why do we not trust storing such an encrypted wallet in the cloud (emailing to one's gmail account, for example)?

I suppose you can do it, but if you don't have to, then don't.  Would you shoot yourself with a bulletproof vest on?  Maybe, maybe not, but you trust the vest and aren't going to die, right?  Many still wouldn't do it, and many wouldn't advise it.  In the end, they're your coins, so you can manage them however you wish.

[Melbustus]

Thanks again for the suggestions, Mike. BIP38 looks great.

I haven't tried out Armory yet, but I like what I'm reading about the offline wallet with online "watch" wallet feature... So here's what I'm thinking of doing:
1) Use Armory to create offline wallet with online "watch" wallet
2) Create encrypted digital backups of the offline wallet
3) Create paper-wallet backups that I encrypt with BIP38

Question: What is the paper-wallet backup that Armory exports? Can that key/whatever-it-is *only* be imported back into Armory, or is it (or does it contain in cleartext) the raw private key(s) which can be imported into different wallets? As noted above, I'd like the backup solution to be as software-independent as possible.

@bullioner - I also like the split paper wallets approach... Will check that out too!


Thanks guys.