Protecting Your Private Keys: Paper Wallets

Lets say the offline storage is set up and the key is generated with sufficient entropy. Now the only attack left is physical. It is rather simple to encrypt your offline machine and there are many good algorithms available for that. In case of a theft, the attacker will not be able to control your keys.

But how to make sure you retain in control of your keys in case of theft, or maybe a fire in your house or other potential disasters. The usual answer it to write the key on a piece of paper. But now the thief may just steal that key, or it might also burn down in a fire. In order to reach security the key needs to be stored securely and at multiple locations.

It quickly becomes clear that this can only be achieved by encrypting the key, writing it down and then depositing it in a few places offline (your parents house, burry it in the garden, ... ???). The problem with usual cryptography is that it does not translate well to the offline world. But since these keys should not be put online we also do not require as much safety.

For this reason rather simple encryption schemes will be enough. You can invent your own. Then the encrypted keys can be distributed and in case of theft or emergency you recover and decrypt one of them and transfer the bitcoin to a new and secure wallet.

Here I post one example of how to create reasonably safe encryption with a human readable password. This password can be weaker than a BIP-39 phrase as it is not intended for online safety. If somebody can guess it, the attacker still needs to find the offline paper containing the encrypted key.

Warning: Do use the code at your own risk. There may be bugs; only use what you understand and do not modify things that you do not understand. There are many ways to compromise the security of your keys. Please consider all keys in this post as compromised and do not use them or send money to their addresses!

1. Encrypt a key (in hex format)
   
   The example key is called WIF_hex, the salt_str is the password and the salt_number is a secret number between 0 and 127 (larger numbers will work but are somewhat pointless and should better be included in the password)
   I then simply salt the WIF, bitshift by 7 to hide the original hex-characters and use the salt_number to hide the bitshift. Then the code is cut up at a random point. This random number is stored in the supplementary hex.
   The output is the new key and as you can see it looks nothing like the old one.

2. Decrypt the key (Need the encrypted key, the supplementary hex, the password and the salt_number)

And the decrypted key matches the original one.

1. Distribute the encoded key and supplementary hex OFFLINE and remember the password and secret number

This encryption has several nice features and only requires you to remember a rather simple password for backup. Many modifications are possible, but always check that you can recover the original key from the backup. For this method, small mistakes lead to much larger consequences in the reconstruction. For example if the attacker has the secret number and password (plus has read this post so he knows the encryption scheme and I did not modify it), but makes a tiny mistake in the encrypted key (in this case the last character is wrong by one, eg. 'e' instead of 'f'), there is a significant mistake in the reconstructed key