Bitcoin Forum
December 03, 2016, 12:30:37 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Mainstream sticking your wallet.dat in the Cloud  (Read 2639 times)
doobadoo
Sr. Member
****
Offline Offline

Activity: 364


View Profile
September 19, 2011, 03:50:00 AM
 #1

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?

"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
1480725037
Hero Member
*
Offline Offline

Posts: 1480725037

View Profile Personal Message (Offline)

Ignore
1480725037
Reply with quote  #2

1480725037
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 19, 2011, 03:59:55 AM
 #2

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?

FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
September 19, 2011, 02:09:54 PM
 #3

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
ctoon6
Sr. Member
****
Offline Offline

Activity: 350



View Profile
September 19, 2011, 07:39:59 PM
 #4

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.

dustintrammell
VIP
Full Member
*
Offline Offline

Activity: 153



View Profile
September 19, 2011, 08:14:37 PM
 #5

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.

Sure you can:

https://bitcointalk.org/index.php?topic=35082.0
doobadoo
Sr. Member
****
Offline Offline

Activity: 364


View Profile
September 20, 2011, 02:57:33 AM
 #6

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 <a="www.transmissionbt.com"> (Transmission) </a>. 

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.

"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 20, 2011, 07:43:18 AM
 #7


What about storing your keys with tahoe-lafs ?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
doobadoo
Sr. Member
****
Offline Offline

Activity: 364


View Profile
September 20, 2011, 02:15:05 PM
 #8

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

"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
ctoon6
Sr. Member
****
Offline Offline

Activity: 350



View Profile
September 20, 2011, 10:52:40 PM
 #9

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.

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 21, 2011, 01:25:52 AM
 #10

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
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.

ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
September 21, 2011, 01:40:41 AM
 #11

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

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
doobadoo
Sr. Member
****
Offline Offline

Activity: 364


View Profile
September 21, 2011, 03:08:55 PM
 #12


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.

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?

"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 21, 2011, 04:22:57 PM
 #13


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.

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.
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.

Also, your 'deterministic' way requires you to remember every password/address.
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.

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.
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.

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... 
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.

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 got broken.  Salting destroys the rainbow attack.

Sound about right?
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.

doobadoo
Sr. Member
****
Offline Offline

Activity: 364


View Profile
September 21, 2011, 07:53:23 PM
 #14

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.

"It is, quite honestly, the biggest challenge to central banking since Andrew Jackson." -evoorhees
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!