Bitcoin Forum
December 07, 2016, 02:46:52 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Text --> Private Key  (Read 2222 times)
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 05, 2012, 08:47:56 AM
 #1

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?
1481122012
Hero Member
*
Offline Offline

Posts: 1481122012

View Profile Personal Message (Offline)

Ignore
1481122012
Reply with quote  #2

1481122012
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
vuce
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 05, 2012, 09:11:56 AM
 #2

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)
Polvos
Hero Member
*****
Offline Offline

Activity: 597



View Profile
July 05, 2012, 09:12:48 AM
 #3

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!!!

jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
July 05, 2012, 09:18:49 AM
 #4

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.



MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
westkybitcoins
Legendary
*
Offline Offline

Activity: 980

Firstbits: Compromised. Thanks, Android!


View Profile
July 05, 2012, 10:22:20 AM
 #5

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 05, 2012, 10:45:34 AM
 #6

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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
July 05, 2012, 10:58:22 AM
 #7

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

14ga8dJ6NGpiwQkNTXg7KzwozasfaXNfEU
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
July 05, 2012, 11:36:25 AM
 #8

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.
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1036


View Profile WWW
July 05, 2012, 11:47:50 AM
 #9

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
DublinBrian
Full Member
***
Offline Offline

Activity: 197


View Profile
July 05, 2012, 11:56:17 AM
 #10

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 Offline

Activity: 1136


View Profile
July 05, 2012, 11:58:46 AM
 #11

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 Offline

Activity: 1148



View Profile
July 05, 2012, 12:04:30 PM
 #12

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?
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
July 05, 2012, 12:06:59 PM
 #13

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?
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 06, 2012, 11:26:04 PM
 #14

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 Offline

Activity: 1218


Gerald Davis


View Profile
July 06, 2012, 11:54:09 PM
 #15

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.  

Lumpy
Full Member
***
Offline Offline

Activity: 237


View Profile
July 07, 2012, 01:02:01 AM
 #16

I use brainwallet.org downloaded to a clean networkless Linux USB.
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
July 07, 2012, 01:06:12 AM
 #17

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.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
July 07, 2012, 01:38:15 AM
 #18

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.  
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
July 07, 2012, 04:26:20 AM
 #19

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
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 07, 2012, 07:14:16 AM
 #20

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.  
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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!