Topic: Encrypted Paper Backups (Read 3784 times)

There's nothing manual about it, it's just one command.  You can even check your work with diff.

You're going to remember the password you chose today, 7 years from now?  Either you re-use passwords way more than you technically should, or your memory is epic.  I'd be much more concerned about the number of things that can go wrong in 7 years that make that backup useless.

Agreed, this is very easy to do.

The issue is it is error prone when done manually. For every 100 times I've done the above manually there is 1 time where something went wrong. If I have a cold wallet that I come back to in 2020 and BTC is priced to the moon, I don't want that to be the time my manual encryption effort screwed up somehow.

The advantage of automation is it eliminates manual mistakes.

It just takes two seconds to encrypt your recovery key, there's no need for this in armory.  Just do it yourself if you want that.

Agreed,

The option already exists to make encrypted digital backups. So I don't really understand the logic behind not supporting the feature. Many users only create digital backups and brainwallet those, so they are already in the exact situation etotheipi says he want to avoid.

All that is being asked for is to provide the same functionality for paper backups as for digital backups.

This stance is the one thing keeping me from using (and recommending) Armory predominantly. I do understand your reasoning and position, but for my personal use-case, I want encrypted backups. I simply am not comfortable with paper wallets due to potential theft, loss, destruction. I very specifically *want* my coins to be unlockable by my brain only. And the last thing I want to worry about is keeping some slip (or M slips) of paper physically secure.

But obviously Armory has lots of great features, so that essentially leaves me to implement my own encrypted Armory backup process which will be MUCH more error-prone than if the feature existed natively in the client.

I really hope you change your mind.

Yes, I'm talking about Shamir's Secret Sharing.  I have developed a full interface around it and will be releasing it along with the RAM-reduced version of Armory.

+1

Can you elaborate what you mean by fragmented backups?
Do you mean Shamir's secret sharing scheme, encryption with a computer generated passphrase, or something else entirely?

For the Mycelium wallet I am leaning towards private key export using BIP38 with a computer generated passphrase which is only displayed on screen (and written on paper by hand). The encrypted backup turned into a JPG image containing the encrypted bits are base58 encoded as text and a QR-code. The JPG is  shared by whatever means your phone supports. If you combine this with import verification I'd say you are pretty well off.

I just want to reiterate my position on this -- I have outlined in the past why I don't want to support directly-encrypted backups.  Not everyone agrees with the reasoning, but I'm sticking to it because the ability to recover your wallet is higher priority than having the extra physical security.

Instead, this is being addressed with the fragmented backups.  It is a perfect mix of redundancy and security, and can be used very similarly to an encrypted backup without the same risks.  Fragmented backups have already been merged into my development branch, and will be part of the next release along with the the RAM reduction.

As Rahl said, you can use gpg to encrypt it to an ascii phrase that you can print out:

gpg -ac armory_backup_phrase.txt

I saved my priv keys on a pendrive, put it in a waterproof box and buried it here: http://www.geocaching.com/geocache/GC242VT_this-is-it
After hiding the box, I disabled this (geo)cache.

Yeah but rahl was already talking about writing down stuff. I guess we have a hybrid paper/brain wallet, in which you write down a really long and/or complex piece of text unable to be reliably memorized and impossible to brute force.

How much space does plausible deniability add?
Like if you have one key that decrypts it to a naughty sex letter and another to the bitcoin key...

Because brainwallets can be brute-forced just by looking at the blockchain (observe an address with funds + use a huge dictionary to find a passphrase that generates a key which matches the address). This has happened multiple times. If you want to brute force an encrypted paper backup you first have to get access to the paper.

Brainwallets are generally a bad idea because the passphrases that normal people can remember are not strong enough to withstand a brute-force attack. If the passphrase is complex enough you have to write it down, and you might as well have written down the private key in the first place.

But if you're going to use a complicated passphrase anyway, why go through the GPG step? Just use a complicated passphrase (or a whole paragraph) as a brain wallet and store the funds in the related address.

Copy paste the paper into PGP/GPG. Encrypt. Print it and the private key ... use a really complicated pass-phrase you also have to write down to be able to remember or it will be too easy to use the copy of your private key? Store in 3 places .... ehh

Doesn't it really come down to security by obscurity no matter how you do if you want to keep it all analogue?

Why not just print the paper wallet to PDF and encrypt it with TrueCrypt?

Yes
I was at the Mycelium booth just on the other side of the aisle all three days of the conference and didn't get a chance to see it. I guess that's my own fault.
Here it how it is currently done with the Mycelium Bitcoin Wallet (in beta): http://www.youtube.com/watch?v=W7V2myIwAuE
Since it is on a smartphone I prefer to use QR-codes. I'll probably add the option to request a device generated password. Do you have a spec for how the armory wallet backup is generated?

Oh you mean like this? 
(it was part of a demo at the Bitcoin conference in May, and will be part of one of the next two major Armory upgrades)

Sorry for reviving this thread...


I am not fond of brain wallets for many reasons (users are notoriously bad at choosing strong passwords, they are easily forgotten, you can attempt a brute force once the address hits the network, etc...)

However, I like ErebusBat's idea of letting software pick a strong password to be displayed in addition to print out an encrypted secret on paper:
 - The password wil be strong
 - The user has no choice but to write it down, but can choose to write it down on a separate sheet.
 - Unlike brain wallets, it is not feasible to brute force until you have the secret stored on paper

I would however still let the user choose to store the secret in plain on paper, and have this as an alternative option.

You're right. I actually just read that rant, but my mistake was looking at this from my point of view rather than from a typical user's point of view. I would use it by printing an unencrypted paper backup, and then just printing out this encrypted backup as another layer of insurance in case the unencrypted backup gets lost/destroyed while I still remember my password. But as you pointed out, the typical user would probably not bother with the unencrypted backup. The other solution you offered, where you'd hand-write an additional code, would do the trick for me.

You could also display a code/sentence on the screen rather than having the user select one.  This more or less forces them to record it somewhere (and as you said, most people would record it on the paper).  If you did this then you would probably want to have the user re-enter for accuracy.

Fr those that truly want an armory brainwallet the methods are out there if they look hard enough, so they are not locked out either.

I've ranted about this before, and I'll resist the urge to ramble about it again, but the gist is:  if there is an encrypted backup option, everyone who's not thinking deeply about it will just use it because it sounds better, and they will end up with no plaintext backup anywhere.  In reality though, if you have no plaintext backup, you have a brainwallet.  Your coins go with you to the grave, or when you forget the decryption passphrase in 10 years (the first time you ever need it).  I believe that it's best for everyone to have a plaintext backup somewhere, and I don't usually support "protecting user's from themselves" (like the drug war, etc), but in this case I think it's preventing a lot of pain. Though, I could probably make some money setting up a service to help people recover their wallets after they forget it...

This is why I was excited about that M-of-N fragmented backups.  Because it really opens up the possibilities for backing up your wallet without effectively creating a brainwallet.

One thing I was thinking of doing was having a screen that says something like: "Print a paper backup with a printer-protection key: create a passphrase that is required to restore your wallet from the paper backup, so that the backup information cannot be stolen by a compromised printer.  Please write the passphrase in the specified area on the paper backup after it is done printing".  This would hide the capability as an extra protective measure, and most users would probably just follow directions and write it on the paper (along with adding extra protection for the Samsung printers with known root exploits).  But an expert user could choose not to write it on there.  That might be enough to sooth my nerves.

This is all coming with the new wallets... if I ever finish them.  It's turning out to be a complete overhaul of some previously-well-tested code, and so it might be a while before I can get them working again (and I probably have to re-write my 1,000+ lines of unit-tests, too).  But I think it will be worth it.

Wouldn't it be easier to just keep the private key in the safe instead of several printed pages?

+1

I would like encrypted backups as well.  I could leave this next to my computer and keep a plaintext backup in a safe.

I agree, but that's why I said I'd keep a plaintext backup, as well. Just not in a safety deposit box. There are always going to be tradeoffs, so it's important to have layers of security againsts both theft and loss. 2-of-3 is also my preferred solution, but this might contribute a beneficial layer of security, and it might be quicker to implement into the GUI.

Nobody does, yet it happens all the time.

Much better in my opinion is 2-of-3 paper backups: Three pieces of paper hidden three places.  You need any two of them to recover the backup, but alone they are useless.  I think they are on their way into Armory.

I know this has been discussed before, but here's why I think encrypted paper backups would be a good idea. Possibly the most realistic failure mode is that the original binary wallet will get corrupted. You could make a few copies on flash drives, but those aren't that reliable either. You could put it on the cloud, but that opens up some more risk. Of course that's why we have paper backups. But I personally wouldn't want to put an unencrypted paper backup in a safety deposit box in a bank. I do think that's a pretty good place for an encrypted paper backup, though.

I don't expect to forget my password anytime soon, so if my digital backups fail, I can always go get that paper. I'll also keep my unencrypted paper backups, in case I do forget my password, but I feel I have to be much more careful with those. Since I don't want to make multiple copies of the unencrypted paper backups, they're more susceptible to loss and damage.