Topic: Text --> Private Key (Read 2831 times)

That would be very serious flaw in sha algorithm.

But if any value in the rainbow table produces the same SHA256 hash (easily collides with different inputs), doesn't that mean SHA256 would be broken?

I guess I don't understand why simple English phrases would be more likely to collide than any other set of random characters, unless the exact same English phrase is chosen.

I use a simple phrase that is easy to remember. It is composed of fairly odd words that don't really go together. I then salt the bejeebers out of it with my own algorithms. I have nested deterministic brainwallets just in case someone really wants my Bitcoinses, my precious Bitcoinses.

If any value in the rainbow table produces the same hash as your passphrase for any one of the thousands of hashing rounds that is a collision.  Once a collision occurs any subsequent rounds will always produce identical hashes.  The more rounds in the chained hashing system the higher the potential for a collision.  If the rainbow table has a value which produces the same hash as your passphrase on any round (not just the first round) then the attacker can generate the same private key.  The attacker may never know what you passphrase is.  It doesn't matter.  Same private key is same private key no matter how it is generated.  This is defeated by including a deterministic salt on each round of the hashing function to ensure that hash for one round can't be compared to any other round.   Of course that warning wasn't intended to be exhaustive.  There are dozens of potential design flaws waiting to render a system cryptographically weak.

Simple version:
Don't try to do it yourself because the odds are you will make some flawed decision based on incomplete knowledge.   Anyone other than a cryptographer is best served by using an existing cryptographically strong peer review system (and yes that include me).  I take my own advice.  FastCash4Bitcoins stores all passwords as bcrypt hashes.  

The passphrase private keys I've used have typically been pretty long.  Seems to me they wouldn't be found in rainbowtables.  For example, they might look something Like this.

I use brainwallet.org downloaded to a clean networkless Linux USB.

Correct however it is important to use existing systems.  A common mistake is for someone to try and "roll their own".  There are a lot of mistakes one can make which reduce the security and without enough knowledge it is tough to even know you have compromised the security.  For example failing to add salt after each iteration will allow an attacker to construct rainbow tables to reduce the workload.  The attacker doesn't have to match the output of the final round he can match the output of any round because once two inputs collide they will always have the same output on each round after that.



PBKDF2 is a good option because it has been extensively reviewed.  

It essentially does this:

That was only 4 iterations.  PBKDF2 normally does 10,000 or more iterations.  Essentially you are increasing the amount of computational power required to attempt one passphrase and thus for a given amount of computing power reducing the number of pass-phrases that can be checked.  SHA256 (and other hashing functions) are fast ... too fast.  You want to increase the computing time to the max that is viable for your scenario.  For example if you are manually generating a new key once a day who cares if it takes 10 seconds.  Make the # of rounds 100,000.  If your CPU can only has 1/10th of a password per second then a GPU likely can't do more than a 100 pps (passwords per second).  The largest farm/pool/botnet is probably <1 million pps.  Now if you are using this as part of some webservice maybe you can't handle an avg execution time of 10s but you probably can handle 0.01s.  You don't want it to be 0.0000000000000001s that is just making it painfully easy for an attacker.  

Oh, I misunderstood that.  I was reading it as 00000000000000000000000000000EBAAEDCE6AF48A03BBFD25E8CD0364141.  Obviously, it's the other way around, and it would actually be very difficult to create a SHA256 hash that isn't a valid Bitcoin private key.  Thanks!

Crypto noob here, I take it by this you mean that you would want to hash a passphrase, then hash the hash some number of times.  Is that right?

Maybe I'm misunderstanding, but the point here is not to generate random keys, but specific keys from passphrases.  Am I misunderstanding what you're asking?

I threw a few not-so difficult pass phrases into the block chain a while back, only '1LdgTMX2MEqdfT3VcDpX4GyD1mqCP8LkYe' has lost coins.

How do we know that apps like Bitaddress.org are serving up genuinely random keypairs?

If someone is not a programmer, and doesnt have the competence to review source code, is there a way to derive a keypair, using old fashioned pen and paper?

Be VERY careful when using private keys that are derived directly from a passphrase. The Bitcoin network does over 2^42 SHA256 operations per second, which is the equivalent to the number of all 8-character alphanumeric passwords every 17 seconds. Any decent miner on the Bitcoin network has enough power to bruteforce any short or easy passphrase-based private key (although deriving the address from a private key is slower than generating it in the first place).

If you want a safe(r) way for deriving keys from text, use repeated hashing using a standard such as PBKDF2 (which is repeated HMAC-SHA1) or Scrypt.

Yep, I've got a little widget on my Mac.  When I want to generate a private key from a passphrase I just type in a passphrase and it'll SHA256 hash it and return it hex.  Then I copy it and past it here.  That website can be saved and run clientside offline, and I keep a copy on a computer that's never been connected to the net.  Brainwallet, FTW.

There's also this site.

https://www.bitaddress.org
then "Wallet details" then enter the text as your private key, it will ask if you want to convert it

Actually it doesn't matter, but it is inefficient to use larger values than the order of G in the ec group.

The 256-bit number of the private key doesn't have to be low. As long as it is less than:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

you'll be safe.

I am sure you know this already, but make sure any text you use for key generation is 'non-obvious'.
You do not want someone performing a dictionary attack against you.

An attacker can use your key definition function to:
1) Generate a key from a dictionary and create the corresponding bitcoin address.
2) See if there is a balance on that address.
3) As they have the private key they can take the bitcoin.
4) Repeat millions of times.

Read this:

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

In one of the latest posts casacius links to this

http://www.casascius.com/btcaddress.zip

Thanks to casascius I have bitcoins stored in my mind. He's the man!!!

Use ripemd-160 to hash the message and blockexplorer to create the address.

Use sha256. (hex will import into blockchain.info and I imagine everywhere else also)