Bitcoin Backup Screenshots

[Rage]

So a few months ago, there was a guy talking about writing a program to securely encrypt and backup your wallet to the cloud. I don't think I've seen any movement on the project so I've taken it up myself. BitCoin Backup will allow you to securely backup and restore your wallet to and from the cloud. Your wallet file will be encrypted using AES256 encryption before it's transmitted (no Dropbox funniness here!) and will be stored on a Truecrypt secured Linux file system.

Here are the first screenshots. Should be available by tomorrow night. I'll need testers so if anyone is interested just let me know.

http://picpaste.com/bitcoin-backup-backup-wallet.png
http://picpaste.com/bitcoinbackup-main-screen.png
http://picpaste.com/bitcoinbackup-restore-wallet.png

Rage

[1715308756]

1715308756

[1715308756]

1715308756

[1715308756]

1715308756

[Comepradz]

Can I run it in windows? open source?

[wenaLIZZ]

I was looking at this for weeks. Really need to have one of those.

[gmaxwell]

So a few months ago, there was a guy talking about writing a program to securely encrypt and backup your wallet to the cloud. I don't think I've seen any movement on the project so I've taken it up myself. BitCoin Backup will allow you to securely backup and restore your wallet to and from the cloud. Your wallet file will be encrypted using AES256 encryption before it's transmitted (no Dropbox funniness here!) and will be stored on a Truecrypt secured Linux file system.

Hard to give any kind of security review without seeing the source—  but a few comments:

Users choose terrible passwords almost universally. It's silly to blame them because they're not changing.   As a result, if you're encrypting something using a password without strengthening you are going to basically be insecure. Please use password strengthening.  I recommend scrypt (http://www.tarsnap.com/scrypt/scrypt-1.1.6.tgz) which is described in this paper: http://www.tarsnap.com/scrypt/scrypt.pdf

The size of someone's wallet leaks information because it grows as you get/send TX but not otherwise.  Someone with access to the "cloud" storage file sizes could potentially backtrack an ID to a user by correlating the change in backup size with activity on the ID.  This is really hard to prevent completely, but it's quiet easy to drastically reduce the amount of information available: Before encrypting pad the size up to some increment.  This will hide some the least significant bits of the size, which have the most entropy. A rounding increment of 4kb wouldn't even use any more space on many filesystems, though a larger one will provide more confidentiality.

[Rage]

Can I run it in windows? open source?

Yes, will be open source and run on Windows, Linux, and Mac.  :-)

[Rage]

Hard to give any kind of security review without seeing the source—  but a few comments:

Source should be available this week :-) I'm going to put it up on Gitorious. Seems to be the hot place for BTC related projects!

Users choose terrible passwords almost universally. It's silly to blame them because they're not changing.   As a result, if you're encrypting something using a password without strengthening you are going to basically be insecure. Please use password strengthening.  I recommend scrypt (http://www.tarsnap.com/scrypt/scrypt-1.1.6.tgz) which is described in this paper: http://www.tarsnap.com/scrypt/scrypt.pdf

Very true and I'm taking that into consideration when I'm writing. On one hand, I really wanted to take the attitude that YOU are responsible for choosing a good password but, let's be honest, that's not really fair for users. So yes, I'm going to use padding and strengthening.  I've got a great module that does some great work with strengthening and I'll have a look at the one you linked to here too.

The size of someone's wallet leaks information because it grows as you get/send TX but not otherwise.  Someone with access to the "cloud" storage file sizes could potentially backtrack an ID to a user by correlating the change in backup size with activity on the ID.  This is really hard to prevent completely, but it's quiet easy to drastically reduce the amount of information available: Before encrypting pad the size up to some increment.  This will hide some the least significant bits of the size, which have the most entropy. A rounding increment of 4kb wouldn't even use any more space on many filesystems, though a larger one will provide more confidentiality.

Excellent points and I appreciate the feedback. I was thinking 4kb would be good too since it's not very large and most filesystems wouldn't even blink at it.  Although, to be honest, the wallet is so small I could almost add an arbitrary bit of padding and it not be a problem.

Thanks!
Rage

[Nesetalis]

oh this is a delicious idea.. I've been poking around wondering about storing things in the cloud securely.
Good luck.
and a side note, toward password.. make it a minimum of 8 characters maximum of 200, must contain letters numbers and atleast one extra character..
may annoy a user or two, and some one may forget their password... but /you/ wont be to blame for their security.

[FooDSt4mP]

So a few months ago, there was a guy talking about writing a program to securely encrypt and backup your wallet to the cloud. I don't think I've seen any movement on the project so I've taken it up myself. BitCoin Backup will allow you to securely backup and restore your wallet to and from the cloud. Your wallet file will be encrypted using AES256 encryption before it's transmitted (no Dropbox funniness here!) and will be stored on a Truecrypt secured Linux file system.

Hard to give any kind of security review without seeing the source—  but a few comments:

Users choose terrible passwords almost universally. It's silly to blame them because they're not changing.   As a result, if you're encrypting something using a password without strengthening you are going to basically be insecure. Please use password strengthening.  I recommend scrypt (http://www.tarsnap.com/scrypt/scrypt-1.1.6.tgz) which is described in this paper: http://www.tarsnap.com/scrypt/scrypt.pdf

The size of someone's wallet leaks information because it grows as you get/send TX but not otherwise.  Someone with access to the "cloud" storage file sizes could potentially backtrack an ID to a user by correlating the change in backup size with activity on the ID.  This is really hard to prevent completely, but it's quiet easy to drastically reduce the amount of information available: Before encrypting pad the size up to some increment.  This will hide some the least significant bits of the size, which have the most entropy. A rounding increment of 4kb wouldn't even use any more space on many filesystems, though a larger one will provide more confidentiality.

The wallet only stores addresses, so transactions don't change it.  And the owner is the only one who can create a new address.

[lulzplzkthx]

I was actually thinking about starting a project just like this today, and then remembered my solution: I use SpiderOak and just have it set to backup my wallet.dat. It keeps the last few versions, meaning I don't have to worry about corruption, and it encrypts ALL of the files backed up.