Mental Bitcoin Wallet: I have real bitcoins stored in my head.

[MrJoshua]

What I did when I stored bitcoins in my head was create a passphrase and a pin number.  The pin number represents the number of times to run SHA256.  I now only remember the "first bits" to the public address, the passphrase, and a pin.  I have my savings account now that I've confirmed it several times with different pass phrases and smaller amounts.  To avoid the change problem I always send the entire balance out, and send change back in manually.

I think it's pretty secure.  Nevertheless it is very easy to hack with a rubber hose... just saying.

Anyone know of a calculator for passphrase entropy?

j

[netrin]

Yeah, just tell me your passphrase in PM and your entropy is 1 bit.

[ffe]

I'd like to re-propose "shadow wallets" that use this idea.

An objection I’ve heard is that the user can be negligent and use weak passwords. This, of course, is a weakness of any cryptographic protection of keys or wallets. The true objection is that there is a transaction out there in the public block chain transferring coin to your key that is subject to a dictionary attack. A thief could scan the block chain for keys generated by weak passwords. He’s not targeting you in particular, but, given human nature, he will harvest a few if this method of generating keys gets popular.

Using a salt and increasing the time / work required to check each key would help. I propose the following functionality for the client:

•   By clicking a “shadow” button, the client is instructed to put aside the main wallet and create a “shadow wallet” at any time.

•   The shadow wallet resides in RAM and is never put on the hard disk. It is actively cleared from memory when the user is done with it and switches back to the main wallet. (Any tricks to keep it off the swap files during memory management should be used.)

•   The shadow wallet is created by generating 1000 keys seeded from a user passphrase as described below. The idea is the user can go to ANY bitcoin client he trusts (on any machine he trusts) and bring up HIS shadow wallet by typing in his passphrase.

•   The client runs through the block chain populating the key balances when the user swaps in a shadow wallet.

•   The salt has to be something unique to that user but is doesn’t have to be secret. I propose the salt be a hash of his full name. This is something he will never forget yet it is enough to thwart a scan of the block chain against a dictionary looking for weak passwords. The attacker would have to target YOU in particular to know what salt to use when checking keys.

•   To increase the work load on the attacker, I propose picking a HASHCOUNT that is the number of SHA256 hashes a typical CPU can calculate in 120 seconds.

•   The INITIALSEED is calculated as SHA256(passphrase, fullname, HASHCOUNT) and the final SEED is calculated as HASHCOUNT repetitions of SHA256(SHA256(SHA256 … SHA256(INITIALSEED))))

So the user has to remember his passphrase and his name. The attacker will despair because each key in the block chain he checks will take him a minute to check against a SINGLE GUESS from his dictionary that may be 100,000 entries of common passwords. This is for an attack against a SINGLE USER that the attacker is targeting because each user will have a different salt.

This architecture completely solves the problem of protecting your standard wallet cryptographically someplace. (As a fall back for people who like to have a thumb drive in hand, you can have a tool generate a very strong passphrase and protect that encrypted on the thumb drive. Nothing at all to remember since with a super passphrase you can leave the fullname null.)

[netrin]

In a centralize authentication system (bcrypt) the required work effort can be increased periodically to keep up with Moore's Law. However, the bitcoin keys already publicly visible in the block chain can not be later 'upgraded'. A key based on a passphrase is only as strong as the passphrase. A username as seed is essentially just a new passphrase' = passphrase+username.

That is not to say I think a deterministic seeded wallet is a bad idea. Indeed it would decentralize the client wallet! I see two use cases: (1) a transferable one time "swiss bank account" (bitbills) and (2) a truly deniable deterministic personal wallet.

[ctoon6]

if somebody pmed you their password, would you not have 0 bits of entropy?

[netrin]

Maybe you're right. I was thinking about the possibility that the password is false.

if somebody pmed you their password, would you not have 0 bits of entropy?

[oOoOo]

You need to take a closer look of what these commands produce.

Code:

gpg --print-md sha256 < /dev/stdin
test

for example produces a completely different string than the one you get at https://bitcointools.appspot.com/?s=test&r=1 when you enter the passphrase "test"

"F2CA1BB6 C7E907D0 6DAFE468 7E579FCE 76B37E4E 93B76050 22DA52E6 CCC26FD2"
versus
"9f86d081 884c7d65 9a2feaa0 c55ad015 a3bf4f1b 2b0b822c d15d6c15 b0f00a08"
!

[kjj]

You need to take a closer look of what these commands produce.

Code:

gpg --print-md sha256 < /dev/stdin
test

for example produces a completely different string than the one you get at https://bitcointools.appspot.com/?s=test&r=1 when you enter the passphrase "test"

"F2CA1BB6 C7E907D0 6DAFE468 7E579FCE 76B37E4E 93B76050 22DA52E6 CCC26FD2"
versus
"9f86d081 884c7d65 9a2feaa0 c55ad015 a3bf4f1b 2b0b822c d15d6c15 b0f00a08"
!

The newline.

Code:

root@inana:~# echo "test" | gpg --print-md sha256
F2CA1BB6 C7E907D0 6DAFE468 7E579FCE 76B37E4E 93B76050 22DA52E6 CCC26FD2
root@inana:~# echo -n "test" | gpg --print-md sha256
9F86D081 884C7D65 9A2FEAA0 C55AD015 A3BF4F1B 2B0B822C D15D6C15 B0F00A08
root@inana:~#

Good demonstration of the avalanche effect, no?

[DiamondPlus]

Exactly.

Every private key is just a 32-byte hex number.  Every 32-byte hex number can be used as a private key.  And hence, every 32-byte hex number has a corresponding Bitcoin address.

Just by coincidence (or perhaps not), the SHA256 hash algorithm can produce a 32-byte hex number from any text input.  And while the output isn't predictable, it always produces the same output given the same input text.

So the idea is just to pair these two ideas.  Pick a passphrase, compute the SHA256 of it, use that as a private key.

All the Casascius Bitcoin Utility does, is calculate the Bitcoin address that corresponds to your 32 bytes as the matching private key.

You aren't remembering the private key itself, you're merely remembering the text that will produce your private key when plugged back into the SHA256 hash algorithm.  Which is good enough.

(When using Casascius Bitcoin Utility / SHA256, the passphrases ARE case sensitive by the way)

[Phinnaeus Gage]

This guy just started using Bitcoin after coming to this forum and only reading this thread:

[goodlord666]

I simply picked a passphrase, and turned it into a bitcoin address with my open source Casascius Bitcoin Utility (available from github).  When I want to spend the funds, I will simply use the same passphrase to generate the same private keys, import them into a real wallet.dat, and then spend them.

Pretty cool.

[Jan]

I'd like to re-propose "shadow wallets" that use this idea.

An objection I’ve heard is that the user can be negligent and use weak passwords. This, of course, is a weakness of any cryptographic protection of keys or wallets. The true objection is that there is a transaction out there in the public block chain transferring coin to your key that is subject to a dictionary attack. A thief could scan the block chain for keys generated by weak passwords. He’s not targeting you in particular, but, given human nature, he will harvest a few if this method of generating keys gets popular.

Using a salt and increasing the time / work required to check each key would help. I propose the following functionality for the client:

•   By clicking a “shadow” button, the client is instructed to put aside the main wallet and create a “shadow wallet” at any time.

•   The shadow wallet resides in RAM and is never put on the hard disk. It is actively cleared from memory when the user is done with it and switches back to the main wallet. (Any tricks to keep it off the swap files during memory management should be used.)

•   The shadow wallet is created by generating 1000 keys seeded from a user passphrase as described below. The idea is the user can go to ANY bitcoin client he trusts (on any machine he trusts) and bring up HIS shadow wallet by typing in his passphrase.

•   The client runs through the block chain populating the key balances when the user swaps in a shadow wallet.

•   The salt has to be something unique to that user but is doesn’t have to be secret. I propose the salt be a hash of his full name. This is something he will never forget yet it is enough to thwart a scan of the block chain against a dictionary looking for weak passwords. The attacker would have to target YOU in particular to know what salt to use when checking keys.

•   To increase the work load on the attacker, I propose picking a HASHCOUNT that is the number of SHA256 hashes a typical CPU can calculate in 120 seconds.

•   The INITIALSEED is calculated as SHA256(passphrase, fullname, HASHCOUNT) and the final SEED is calculated as HASHCOUNT repetitions of SHA256(SHA256(SHA256 … SHA256(INITIALSEED))))

So the user has to remember his passphrase and his name. The attacker will despair because each key in the block chain he checks will take him a minute to check against a SINGLE GUESS from his dictionary that may be 100,000 entries of common passwords. This is for an attack against a SINGLE USER that the attacker is targeting because each user will have a different salt.

This architecture completely solves the problem of protecting your standard wallet cryptographically someplace. (As a fall back for people who like to have a thumb drive in hand, you can have a tool generate a very strong passphrase and protect that encrypted on the thumb drive. Nothing at all to remember since with a super passphrase you can leave the fullname null.)

I have been working on a java library for some time now, which allows you to create a bitcoin client that works along the lines you describe.
The technique of spending CPU cycles on deriving a seed is also called key stretching. I am using Scrypt (http://www.tarsnap.com/scrypt/scrypt.pdf) for this purpose, which not only requires CPU cycles, but also demands a certain amount of memory for its calculations. This makes hardware based brute force attacks much more expensive and less practical, as the chip will require too much cache memory.

I am expecting to have the first version of the library publicly available within a week.

[ffe]

I wanted to point out this thread

StrongCoin

He’s building a web site that keeps part of your wallet but, crucially, not the secret keys. The secret keys are kept in your client on your machine.

He refers to this thread as a source of ideas for his web site.

I’d like to applaud the combination. A web site that enables mental bitcoin wallets. The web site would:

•   Keep an up to date block chain.
•   Keep a list of all your public keys and their balances.
•   Respond to balance queries from the client
•   Accept fully signed transactions from the client and transmits them over the bitcoin network
•   Pushes a vanilla JavaScript client to the user’s browser

The user client would:

•   Be a phone app or a JavaScript client that downloads from the web site (would normally be catched)
•   Accept your name and password and locally create all your keys (mental wallet as described in this thread)
•   Query the web site for the balances on the keys
•   Allow the user to send coin by creating signed transactions and sending them to the web site for publication.

Notice, the user has no need to trust the web site. Also this client is an excellent candidate to be written as a phone app since it has no need to deal with the block chain.

[casascius]

...
•   Keep an up to date block chain.
•   Keep a list of all your public keys and their balances.
•   Respond to balance queries from the client
•   Accept fully signed transactions from the client and transmits them over the bitcoin network
•   Pushes a vanilla JavaScript client to the user’s browser

The user client would:

•   Be a phone app or a JavaScript client that downloads from the web site (would normally be catched)
•   Accept your name and password and locally create all your keys (mental wallet as described in this thread)
•   Query the web site for the balances on the keys
•   Allow the user to send coin by creating signed transactions and sending them to the web site for publication.

Notice, the user has no need to trust the web site. Also this client is an excellent candidate to be written as a phone app since it has no need to deal with the block chain.

Well, the web site would have to be trusted to at least SOME extent... to:

• Not have been rooted and be serving malicious content placed there by a hacker
• Serve the javascript client that it claims it serves, rather than serving something that collects the password...
• Tell the truth about what transactions are in the block chain when asked

• A server that lied about the value of a particular input transaction (by understating it) could convince a client to sign off a transaction that was actually worth more than the client thought it was... assuming the client had a check to confirm it was signing a transaction for the amount it was told, the extra funds could still be concealed as a large transaction fee
• A server could lie to the client about how many bitcoins he really has, making him think he has more than he does, by telling the client about past transactions that have already been spent, without telling the client about the transactions that spent them... the client will be convinced and have no way to verify, it just won't be able to produce a valid transaction to spend those coins

[/list]

[ffe]

Well, the web site would have to be trusted to at least SOME extent... to:

• Not have been rooted and be serving malicious content placed there by a hacker
• Serve the javascript client that it claims it serves, rather than serving something that collects the password...
• Tell the truth about what transactions are in the block chain when asked

• A server that lied about the value of a particular input transaction (by understating it) could convince a client to sign off a transaction that was actually worth more than the client thought it was... assuming the client had a check to confirm it was signing a transaction for the amount it was told, the extra funds could still be concealed as a large transaction fee
• A server could lie to the client about how many bitcoins he really has, making him think he has more than he does, by telling the client about past transactions that have already been spent, without telling the client about the transactions that spent them... the client will be convinced and have no way to verify, it just won't be able to produce a valid transaction to spend those coins

[/list]

I agree about the javascript. It could cost you your coin. Maybe you should get your client from a trusted source. (Wait! circular logic here. Are we saying the only trusted client is the original one?)

The rest is just maliciousness for the sake of evil. The site can't steal your coins if you're careful and would quickly lose credibility if it tried those things.

Still, much better than the e-wallet solutions that are out there today.

[notme]

That is bloody brilliant.  I mean, really, really, really.

Bloody brilliant!  Given a popular and accessible conversion utility and interface...well.  I have to go outside and breath slowly now.

(emphasis mine)

Be careful using common phrases... collisions could be costly.  I personally will only use this technique after I develop my own custom preprocessor for the passphrase before passing it to the sha256 algorithm.

[notme]

Guess I should have read the rest of the thread first .

[casascius]

I really wish MtGox would just offer a paper bitcoin wallet generator (either random or from a passphrase) where you could just print your paper wallet straight from MtGox.  And a corresponding function to redeem private keys back into your MtGox account.  The same with every other trusted Bitcoin bank-like site.

MtGox is already halfway there with their "MtGox codes" but those require the BTC to be kept in MtGox and can't be taken anywhere else.  How nice if the average joe could just print a paper wallet, send their BTC to it, and stash it in a safe.

With just two functions, people could keep all of their bitcoins offline until the instant they want to spend them, mooting the need for many things like wallet encryption in the client, or long step-by-steps on how to TrueCrypt, or how to rescan wallet.dat.  In fact, that pretty much moots the need for the average joe to ever bother downloading the bitcoin client in the first place unless he wants to mine.

Perhaps I need to offer my paper bitcoin wallet generator in a free web-based edition.

[Wolenber]

Perhaps I need to offer my paper bitcoin wallet generator in a free web-based edition.

Please, please do.

[sje397]

You could generate the wallet from a fingerprint or retina scan.