I am not sure rainbow tables would be a concern. Rainbow tables would help someone get your passphrase from your 32-byte private key, but they don't even have that. They don't even have your public key either if you have never sent funds from the address.
That's not the way they would do the attack. They would build a rainbow table of a few trillion passphrases and the corresponding bitcoin addresses. Everytime a new bitcoin address appeared in the hash chain, they would check that address against the rainbow table. If they found a match, they would derive the private key again and claim the funds immediately. 
Topic: Mental Bitcoin Wallet: I have real bitcoins stored in my head. - page 5. (Read 12759 times)
After some trying I found a SHA256 hash generator for Linux:
$ gpg --print-md sha256 < /dev/stdin
which gives the same results as
$ gpg --print-md sha256
where is a file containing
and also the same results as
http://www.xorbin.com/tools/sha256-hash-calculator in which you type:
$ gpg --print-md sha256 < /dev/stdin
which gives the same results as
$ gpg --print-md sha256
where
and also the same results as
http://www.xorbin.com/tools/sha256-hash-calculator in which you type:
Cool, so am I to believe that I can use this method to generate a bitcoin address and then use it for transactions? If so... you win the internet for the day and I will donate 0.05btc to you (hey it's better than nothing).
But it's not just random jibberish with good variety of low and high caps, numbers, symbols etc, people are gonna use words and phrases that tend to make sense
YepI will force users to use some special characters
Obviously, if someone you can't trust knows or can guess your passphrase, you are doomed.
That and you have to wear a tinfoil hat so the government can't read your thoughts from space...
But it's not just random jibberish with good variety of low and high caps, numbers, symbols etc, people are gonna use words and phrases that tend to make sense
Are people really gonna be imaginative enough with the phrases for the risk of collision to be negligible?
My program refuses passphrases below 40 characters or 7 words, casascius should do that too... So who takes the prize for being the first person in history to store money in their mind?
That prize was probably awarded centuries ago. Early stock markets worked that way, traders just kept the transactions of the day in their heads. They'd be written down and/or directly executed only after the market closed.
Are people really gonna be imaginative enough with the phrases for the risk of collision to be negligible?
hero member
Activity: 836
Merit: 1007
"How do you eat an elephant? One bit at a time..."
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)
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)
This sounds pretty awesome. Do you have a direct link to this utility?
Thanks!
Say HI to address collisions. 
Only if two people use the same passphrase.'123456' is pretty common
Sure, but good luck grabbing a large number of coins out of that one's resulting address, what is its average time until next checked for coins by rainbow corp or whoever does the rainbow stuff?
-MarkM-
Edit so anyway, obviously we need to use "123456" (or whatever we manage to memorise as our hash type cypher passphrase) to generate a table of 256 distinct hash routines, so that our hash type selection phrase's hash can be used to look up hash routines to use to hash our actual phrase. Thus forcing users to use 123456 three times in a row, which would result in...
Say HI to address collisions.
Only if two people use the same passphrase.'123456' is pretty common
Absolutely. You want at least 128-bits of entropy in the passphrase to provide security comparable to what ECDSA is already providing. Note that you can increase the number of effective bits by using a more complex algorithm, such as multiple iterations. You'd still be vulnerable to rainbow tables.
I am not sure rainbow tables would be a concern. Rainbow tables would help someone get your passphrase from your 32-byte private key, but they don't even have that. They don't even have your public key either if you have never sent funds from the address.
Say HI to address collisions.
Only if two people use the same passphrase. Obviously, if someone you can't trust knows or can guess your passphrase, you are doomed. 
After some trying I found a SHA256 hash generator for Linux:
$ gpg --print-md sha256 < /dev/stdin
which gives the same results as
$ gpg --print-md sha256
where is a file containing
and also the same results as
http://www.xorbin.com/tools/sha256-hash-calculator in which you type:
$ gpg --print-md sha256 < /dev/stdin
which gives the same results as
$ gpg --print-md sha256
where
and also the same results as
http://www.xorbin.com/tools/sha256-hash-calculator in which you type:
Say HI to address collisions.
So who takes the prize for being the first person in history to store money in their mind?
Absolutely. You want at least 128-bits of entropy in the passphrase to provide security comparable to what ECDSA is already providing. Note that you can increase the number of effective bits by using a more complex algorithm, such as multiple iterations. You'd still be vulnerable to rainbow tables.
To be clear though, if your passphrase has 128-bits of entropy in it, such that an attacker would need to try on the order of 2^128 passphrases to hit on yours, this scheme is no less secure than straight ECDSA. (Except that both people know the private key, so either can claim the funds.)
To be clear though, if your passphrase has 128-bits of entropy in it, such that an attacker would need to try on the order of 2^128 passphrases to hit on yours, this scheme is no less secure than straight ECDSA. (Except that both people know the private key, so either can claim the funds.)
Yeah, I have some bitcoins in my head too. This is what I talked about with ThoughtCoins a few weeks ago:
https://bitcointalksearch.org/topic/thoughtcoin-29187
Just remember that the entropy (read: cryptographic strength) of even a long passphrase with numbers and symbols is quite a bit lower then an actual private key. In other words where it is impractically to search the entire key space of private keys it is possible to search the passphrase keyspace looking for valid wallets. Whereas the encryption of your wallet file with a passphrase requires access to your encrypted wallet to try to brute force your passphrase, a passphrase only wallet or ThoughtCoins as I called it requires nothing, anyone can start brute forcing that keyspace right now. Nevertheless, choose a good passphrase, and bitcoins in your head have some very interesting properties, as I discussed in my thread.
Information on the entropy of passphrases: http://en.wikipedia.org/wiki/Passphrase
j
https://bitcointalksearch.org/topic/thoughtcoin-29187
Just remember that the entropy (read: cryptographic strength) of even a long passphrase with numbers and symbols is quite a bit lower then an actual private key. In other words where it is impractically to search the entire key space of private keys it is possible to search the passphrase keyspace looking for valid wallets. Whereas the encryption of your wallet file with a passphrase requires access to your encrypted wallet to try to brute force your passphrase, a passphrase only wallet or ThoughtCoins as I called it requires nothing, anyone can start brute forcing that keyspace right now. Nevertheless, choose a good passphrase, and bitcoins in your head have some very interesting properties, as I discussed in my thread.
Information on the entropy of passphrases: http://en.wikipedia.org/wiki/Passphrase
j
Did you run that past a cryptographer first? I haven't read FIPS 186-3 in detail, but I seem to recall that ECDSA keypair generation involved more than tossing a bunch of bits together.
It is a well-known and well-understood property. Yes, ECDSA keypair generation does involve more than tossing a bunch of bits together. You follow the normal ECDSA keypair generation process except instead of generating a random private key, you use a hash.To an attacker who does not know the input to a hash algorithm, the output of that hash algorithm is effectively random.
Quote
Also, did you test this?
It's a well-known property of ECDSA. It has been used to transfer bitcoins. (You can actually do it with RSA as well, it's just more complicated. You must use the hash to seed an agreed-upon PRNG.)
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)
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)
Did you run that past a cryptographer first? I haven't read FIPS 186-3 in detail, but I seem to recall that ECDSA keypair generation involved more than tossing a bunch of bits together.
Also, did you test this?
Jump to: