SgtSpike (OP)
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
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?
|
|
|
|
vuce
|
|
July 05, 2012, 09:11:56 AM |
|
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)
|
|
|
|
|
jim618
Legendary
Offline
Activity: 1708
Merit: 1066
|
|
July 05, 2012, 09:18:49 AM Last edit: July 05, 2012, 10:43:14 AM by jim618 |
|
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.
|
|
|
|
westkybitcoins
Legendary
Offline
Activity: 980
Merit: 1004
Firstbits: Compromised. Thanks, Android!
|
|
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.
|
Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
... ... In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber... ... ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)... ... The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
|
|
|
vuce
|
|
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:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
you'll be safe.
Actually it doesn't matter, but it is inefficient to use larger values than the order of G in the ec group.
|
|
|
|
drakahn
|
|
July 05, 2012, 10:58:22 AM |
|
https://www.bitaddress.orgthen "Wallet details" then enter the text as your private key, it will ask if you want to convert it
|
14ga8dJ6NGpiwQkNTXg7KzwozasfaXNfEU
|
|
|
proudhon
Legendary
Offline
Activity: 2198
Merit: 1311
|
|
July 05, 2012, 11:36:25 AM |
|
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) 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.
|
Bitcoin Fact: the price of bitcoin will not be greater than $70k for more than 25 consecutive days at any point in the rest of recorded human history.
|
|
|
Pieter Wuille
Legendary
Offline
Activity: 1072
Merit: 1181
|
|
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.
|
I do Bitcoin stuff.
|
|
|
DublinBrian
|
|
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?
|
|
|
|
TTBit
Legendary
Offline
Activity: 1136
Merit: 1001
|
|
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.
|
good judgment comes from experience, and experience comes from bad judgment
|
|
|
proudhon
Legendary
Offline
Activity: 2198
Merit: 1311
|
|
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?
|
Bitcoin Fact: the price of bitcoin will not be greater than $70k for more than 25 consecutive days at any point in the rest of recorded human history.
|
|
|
proudhon
Legendary
Offline
Activity: 2198
Merit: 1311
|
|
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?
|
Bitcoin Fact: the price of bitcoin will not be greater than $70k for more than 25 consecutive days at any point in the rest of recorded human history.
|
|
|
SgtSpike (OP)
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
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:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
you'll be safe.
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!
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
July 06, 2012, 11:54:09 PM Last edit: July 07, 2012, 12:07:37 AM by DeathAndTaxes |
|
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. 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: 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.
|
|
|
|
Lumpy
|
|
July 07, 2012, 01:02:01 AM |
|
I use brainwallet.org downloaded to a clean networkless Linux USB.
|
|
|
|
proudhon
Legendary
Offline
Activity: 2198
Merit: 1311
|
|
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. 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.
|
Bitcoin Fact: the price of bitcoin will not be greater than $70k for more than 25 consecutive days at any point in the rest of recorded human history.
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
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. 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.
|
|
|
|
cbeast
Donator
Legendary
Offline
Activity: 1736
Merit: 1014
Let's talk governance, lipstick, and pigs.
|
|
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.
|
Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
|
|
|
SgtSpike (OP)
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
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. 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. 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.
|
|
|
|
|