I follow the procedure of making a cold storage wallet: downloaded copy of bitaddress.org using an off-line computer booted with Ubuntu from CD.

Instead of printing out the private keys and corresponding addresses for my bitcoin, I simply use a JavaScript file (http://prgomez.com/ursa/) to encrypt the private key, while I am using Ubuntu. I then keep together the address and encrypted bitcoin private key safely so I don’t lose it, but with no need for special security. All I need to keep in paper is my 80 bit plus password for the encryption of the key.

Logically, this seems to me safe, though I have so far only entrusted small sums of money to this procedure.

Is it safe?


It's challenging to answer this without a clear definition of what you mean by "safe." I'll assume your two main concerns are (A) loss by theft; and (B) loss by user error.

For (A) you're "safe." You followed offline cold storage wallet generation procedure and your private key was not exposed in an online-hackable way. You have the same level of theft protection as an offline-generated paper wallet -- with the added level of protection that your private key is encrypted. If your paper is lost or stolen, another party would have to know your method of encryption as well as your password. (Naturally, if your password is stored on the paper, then you effectively have the same security as a non-encrypted wallet in the case of theft or loss of the physical paper.)

For (B) there are a number of possibilities, but here's some scenarios to consider.

  • Are you entering the unencrypted or the encrypted private key into bitaddress.org? If the latter, then you gain no benefit from the encryption and might be confused when attempting to retrieve your funds.

  • How confident are you that you'll be able to recover the unencrypted private key when the need arises? Your use of a home-brewed step here makes it a good candidate for something to go wrong. Are you prepared to keep a working copy of the encryption/decryption software -- exactly as it was used at the time of wallet creation -- for the entire lifetime of the paper wallet? Did you test decryption at the time you generated the wallet to ensure the decrypted private key matches the original unencrypted key? Have you tested retrieving funds to ensure that your process works from end-to-end? Are you going to remember all the steps involved 10 years from now or do you need to keep written notes? Etc.

  • Same with any password-protected item, how confident are you that you'll be able to remember the password when the time comes? People forget passwords so often that nearly every website with password-based authentication includes a recovery mechanism. Are you printing the password along with the paper wallet? If so, then what is the purpose of the encryption? Are you printing the password and keeping it elsewhere? If so, then will you be able to find it when the time comes? (How many times have you put something where you'll "never forget where it is" only to discover you can't find it later?)

  • Same with any paper wallet, how safe is yours from physical loss, disaster, etc.? Are you planning to keep a backup copy? How do the backup copies affect your risk of theft? How long will the paper and ink last?

Have a look into BIP0038. bitaddress.org can generate BIP0038-encrypted private keys. Three benefits of this are:

  1. BIP0038 uses scrypt with parameters intentionally tuned to make brute-force password guessing attacks very slow. In this thread folks were getting 7 password guesses per second at the time, which is not very many for a brute-force attempt.

  2. bitaddress.org generates the wallet in such a way that the actual private key never exists in the computer's memory while the wallet is being created. Counter-intuitive, but true -- it uses the "EC multiply" variation of BIP0038. (Of course your password exists in memory, so you will likely still want to do this offline.)

  3. It is more of a standard than your home-brewed encryption step. BIP0038 is not officially an adopted standard as of this writing; but enough folks support it at this time that it may as well be a de facto standard. This means you have several options for retrieval, with less chance for human error or other issues presenting an obstacle to retrieving your funds.

  • Excellent practical points. The reason for the "home brewed" procedure is that I know what I am doing and why. My main worry is A i.e. hacker theft. The javascript file (prgomez.com/ursa) for encryption is stored in several places, and often used as I use it to encrypt sensitive emails. Will take a look at BIP0038, but don't understand it yet. – Peter Dec 17 '14 at 16:12

Your Answer

