Topic: Mainstream sticking your wallet.dat in the Cloud (Read 2996 times)

Thanks for the enlightening discussion all, esp you maged.  I don't quite understand this deterministic stuff.  The wallet.dat file is thus generated from the passphrase.   Okay, sounds like a shortcut.  But this can't be as secure as my idea to just take the wallet and store the encrypted file in the clear. You wouldn't have to worry about passphrase collisions or even strength.  If you use a username to salt, and ask for a passphrase and date you have all you need to make something very well encrypted. 

The wallet.dat file can be zipped down to a few k....  Why not zip, encrypt and store on a public server like people currently do with their public pgp keys  (eg the mit public key server).  Its really not as hard as you think, it would require a trivial amount of server space/bandwidth for the whole community.

PGP email works like this.  All i gots to do is check mark the encrypt box in my client and if the recipient has a public key on file with that address, bang.  MSG encrypted and sent.   

In my world when sending a transaction, you input the user/pass/date, your encrypted wallet is retrieved by the instance your running.  It executes  in memory, then zipcrypts and uploads the updated wallet.dat. 

Am i correct in that all you need to spend btc is the public address and the private key right?  these are trivially small amounts of data and should be hosted, not accessed locally.

On the contrary, deterministic wallets are already on the roadmap to be added to the Bitcoin client (don't quote me on that, since I'm not completely sure that's true), so this would require significantly less work than your idea. With your idea, we need to implement a side-channel for distributing and storing encrypted wallets. With my idea (well, it's not really my idea...), the password is the wallet.

On the contrary, a single password can generate a large number of addresses. Do a forum search for "deterministic wallet" and be prepared to have your mind blown. I know mine was.

While it's somewhat true that you would more likely be targeted under the deterministic wallet system, under your idea, you are also more vulnerable to untargeted attacks since attackers would know that most encrypted wallets would contain at least some bitcoins. I do concede, though, that bruteforcing all deterministic wallet at once would be easier, since you just need to check if an address exists for each password instead of testing each encrypted wallet. Maybe your idea of using usernames as a salt might fix that, though.

That being said, it would be hard to actually target a deterministic wallet. The reason for this is that you can only know what addresses you cracked after you crack them, not before.

You can do that same thing for deterministic wallets. Your password can go through encryption before being hashed by encrypting it with itself. After you hash it, you can again encrypt it with either the password, the encrypted password, or the hash of the encrypted password, and then hash it again just for the hell of it. As you would anytime you are dealing with passwords, the user could set the strength of the key by requiring any part of the process to run more times (they'd need to remember what they set the strength to, though). They could make it so that it'd take 10 minutes for an average computer today to generate their master private key if they wanted to, regardless of what the password is. Of course, the same can be done in your idea.

That would likely be secure enough, yes. Whichever way you do it, though (either encrypting the wallet and sending it off or using seeded deterministic wallets), I still wouldn't trust my life's savings in it.

Yeah, we're splitting hairs. I was just thinking about how to use the current system with a wallet.  It maytake more dev work to do it your way, and its less robust.

Also, your 'deterministic' way requires you to remember every password/address.   encrypting the current wallet lets you maintain lots of addresses and reduces the chances that some one will target you .  Remember blockexplorer will tell every one which address should target for a big payoff.  It would be harder to find the "fat" addresses along with the specific wallet to attack.  B/c username is not associated with an address, just a  an encrypted wallet file that can access unkown addresses.

As far as entropy.  I propose doing it the wallet way b/c you can control the complexity of the encryption perhaps with a bit more granularity.  Sha256 followed by blowfish, then aes etc... 

If we use a username as a salt (eg like paypayl), require 9+ character pws with punctuation, and tack on a special date (Dec 25 0000). It would be very hard for an attacker to break it.   We lost hashes on this site. the pws were salted by username.  I bet even a simple 123456 password wasn't broken.  Salting destroys the rainbow attack.

Sound about right?

You could use a long salt which is likely to be unique to yourself and hard to forget (such as your's email address) then, with a suitable algorithm which prevents quick exhaustive search, the password could be considerably shorter than an address and the entropy requirements likewise reduced. The length (and quality) of your password is determined by how much work you want your attacker to do before you don't mind them taking your coins. Saying that this is "incredibly insecure" seems to be setting a rather high bar for "incredible insecurity".

ByteCoin

Again, this can be achieved by using a password to seed a deterministic wallet. It's literally the same thing you're trying to do, except that the "wallet" is stored directly in the blockchain. (more precisely, the wallet would no longer exist, or need to exist, since it's generated by a password)

Of course, it would be incredibly insecure unless your password was as long as an address and had a good amount of entropy.

you loose half your security just by giving out your wallet. whats wrong with keeping it on a flash drive/dvd (id suggest looking into the M-Disc). if you want to keep it on a flash drive, use 2 or more drives, and keep them inside a Faraday cage in case of an EMP. i think you can just wrap something in cloth, then some aluminum foil, and it might have similar effects if your cheap. i think that may work, but you should do further research if you want to use it for real.

yes what  we're describing is some kind of Cloud-based RAID.  A swarm, just like bittorrent.  Infact since there are so many open sourced BT clients, i suggest copy and paste. 

The real trick is encrypting the wallet so that every one can see/copy it but not penetrate it.  I'm no cryptographic expert, but between a user name/passphrase and and maybe a 3rd piece like a date, the wallet can be secured and then stored in the open by the client. 

This solves all kinds of problems.  1) losing a wallet  2) transporting wallet to new machine 3) wallet trojans to steal wallet.dat

What about storing your keys with tahoe-lafs ?

But yet the point is that the wallet file is distributed amongst the network nodes, so that i can bitcoin from my ipod, laptop and desktop all the same.  This is the sort of idea i'm proposing.  Can't this 'super-computer' like network securely store a few thousand 90K wallet.dat files?? 

The idea is to hide your wallet in plain sight, amongst the network. 


Otherwise, an alternate idea would be to build an HTTPS server into the bitcoin client to host a secure site you can access to bitcoin from your smartphone.  This is similar to how the bittorrent app i use www.transmissionbt.com"> (Transmission) . 

Thoughts? 

And as for wallet encryption.  Yes, the wallet would need to be secured from a rainbow attack.  Best way to do that would be to use 2 algorithms: one well used, one less used/obscure (eg, Sha256, Blowfish384).  And of course you'd salt the hash with a user name.    I would add an extra feature:  Special day.   So to get at a wallet you would enter user name: JDoe Pass-phrase: Ihaveasecret-76 then a "special" date:  9/23/01  (Jon Doe's anniversary).  This date could be converted and appended to the pass-phrase for extra randomness. 

All the bitcoin user *needs* to remember is those 3 pieces of info: username, passphrase, special date.  With those three data points, from any secure instance of the BTC client, a user should be able to access his wallet and spent his BTC.  Again, the actually wallet.dat, in encrypted form, is stored in the swarm of the Bitcoin nodes.

Sure you can:

https://bitcointalksearch.org/topic/mental-bitcoin-wallet-i-have-real-bitcoins-stored-in-my-head-35082

you cant use a password to make a private key from. if you do, you make yourself very vulnerable to rainbow table attacks if you use passwords less than 14 characters i think. you ideally want at least 20 characters or more.

All you need is your private key(s), if you put them in a cloud with a slightly shorter password than the key length you still have to keep your key with you and safe. If it is much shorter to the point that you can remember it then you are giving up safety. I don't think there is anything to be gained here.

You don't even need to store the wallet in the cloud - the addresses that coins are sent to can be based directly off of a password. That being said, what is your suggestion for making it SIGNIFICANTLY less profitable to crack these deterministic addresses than it is to mine?

I don't get it.  We have close to a gig for the transactions database and it's stored on every client's machine, but the wallet.dat is kept only on the one client its installed on.  Does this make any sense? 

How's this for a feature idea:  Gavin, you already believe the whole dam thing will be in the cloud, so why not do it?  Just like when wikileaks would pre upload a bittorrent of some encrypted file with the threat that it would release the keys, why doesn't the Bitcoin Client just encrypt the wallet.dat and stick that sucker in the cloud FOR the user.  What i'm saying is hide every one's wallet in plain sight!

The file is like what 92KB?   There are how many users/wallets?   Why doesn't each client just take its wallet, upload it to the neighboring clients, who then append it to their wallet keychain, and upload theirs back to the client.  When the wallet.dat chains hit some arbitrary size, like 1 GB, they should split somehow.  You know, most clients will have your wallet.dat.  What I am describing is essentially a bittorent swarm for hosting the wallet.dat file.  HELLO!!!  Can't you geeks just like copy and paste from a bittorent opensource that handles the magnetlinks?  This prob's been solved guys!

With a P2P Cloud-hosted Wallet.dat database, you can access your bitcoin anywhere from just an SSL cloud web-app.  And as long as you trust the instance being presented to you by the server, you can rest assured that your wallet is safe.  The thin client would simply query otherclients limewire-like for its wallet.dat file.   Or maybe it would need to query a wallet.dat database and pay a small fee.

If implemented users would not need to worry about where their wallet.dat is stored bc it will be everywhere.  They would just need their password.  It would simultaneously eliminate the need for backups, and the need to take their one client everywhere just to be able to make or receive a payment. 

 I mean, why can''t this sucker function like an online wallet does, while using bittorrent tech to swarm-store the wallet.dat file.  By which I mean every client would buffer a few megabytes like strips of a massive SAN. 

Thoughts?