|
Title: Text --> Private Key Post by: SgtSpike on July 05, 2012, 08:47:56 AM What's the best/easiest way to turn text into a VALID Bitcoin private key (one that starts with a 5)? As I understand it, a valid private key must be a 256-bit number, but a very low 256-bit number. Is this true?
Title: Re: Text --> Private Key Post by: vuce on July 05, 2012, 09:11:56 AM Use sha256 (http://hash.online-convert.com/sha256-generator). (hex will import into blockchain.info and I imagine everywhere else also) Title: Re: Text --> Private Key Post by: Polvos on July 05, 2012, 09:12:48 AM Read this:
https://bitcointalk.org/index.php?topic=35082.0 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!!! Title: Re: Text --> Private Key Post by: jim618 on July 05, 2012, 09:18:49 AM 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. Title: Re: Text --> Private Key Post by: westkybitcoins on July 05, 2012, 10:22:20 AM 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. Title: Re: Text --> Private Key Post by: vuce on July 05, 2012, 10:45:34 AM The 256-bit number of the private key doesn't have to be low. As long as it is less than: Actually it doesn't matter, but it is inefficient to use larger values than the order of G in the ec group.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 you'll be safe. Title: Re: Text --> Private Key Post by: drakahn on July 05, 2012, 10:58:22 AM https://www.bitaddress.org
then "Wallet details" then enter the text as your private key, it will ask if you want to convert it Title: Re: Text --> Private Key Post by: proudhon on July 05, 2012, 11:36:25 AM Use sha256 (http://hash.online-convert.com/sha256-generator). (hex will import into blockchain.info and I imagine everywhere else also) 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 (https://www.bitaddress.org/bitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html). 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 (http://www.forbes.com/sites/jonmatonis/2012/03/12/brainwallet-the-ultimate-in-mobile-money/), FTW. There's also this (https://bitcointools.appspot.com/) site. Title: Re: Text --> Private Key Post by: Pieter Wuille on July 05, 2012, 11:47:50 AM 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. Title: Re: Text --> Private Key Post by: DublinBrian on July 05, 2012, 11:56:17 AM 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? Title: Re: Text --> Private Key Post by: TTBit on July 05, 2012, 11:58:46 AM 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. I threw a few not-so difficult pass phrases into the block chain a while back, only '1LdgTMX2MEqdfT3VcDpX4GyD1mqCP8LkYe' has lost coins. Title: Re: Text --> Private Key Post by: proudhon on July 05, 2012, 12:04:30 PM 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? 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? Title: Re: Text --> Private Key Post by: proudhon on July 05, 2012, 12:06:59 PM 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. 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? Title: Re: Text --> Private Key Post by: SgtSpike on July 06, 2012, 11:26:04 PM The 256-bit number of the private key doesn't have to be low. As long as it is less than: 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!FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 you'll be safe. Title: Re: Text --> Private Key Post by: DeathAndTaxes on July 06, 2012, 11:54:09 PM 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? 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? 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. Quote from: someone important The problem with bad cryptography is that it looks just like good cryptography. PBKDF2 is a good option because it has been extensively reviewed. It essentially does this: Code: hash = SHA256(salt + SHA256(salt + SHA256(salt + SHA256(salt + password)))) 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. Title: Re: Text --> Private Key Post by: Lumpy on July 07, 2012, 01:02:01 AM I use brainwallet.org downloaded to a clean networkless Linux USB.
Title: Re: Text --> Private Key Post by: proudhon on July 07, 2012, 01:06:12 AM 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.
Quote 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. Title: Re: Text --> Private Key Post by: DeathAndTaxes on July 07, 2012, 01:38:15 AM 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. Quote 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. 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. Title: Re: Text --> Private Key Post by: cbeast on July 07, 2012, 04:26:20 AM 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.
Title: Re: Text --> Private Key Post by: SgtSpike on July 07, 2012, 07:14:16 AM 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. Quote 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. 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. 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. Title: Re: Text --> Private Key Post by: waspoza on July 07, 2012, 08:28:51 AM 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. That would be very serious flaw in sha algorithm. |