I don't understand why everyone writes about billions of keys per second. It's really slower than you think, at least for now.
Calculating sha256 is really just a tiny fraction of calculating an ecdsa keypair.
While vanitygen only does 1 EC addition, calculating an ecdsa key from seed needs at least two full blown multiplications of big numbers.
Long story short, CPUs only can generate about 1,000 keys a second, modern GPUs can calculate 20,000 keys a second, tops.
Not billions, thousands. 6 orders of magnitude smaller than billions. 1,000 times slower than vanitygen.
Topic: Results of dictionary attack on SHA256 hashed keys (Read 12544 times)
Probably a stupid question but how much space would be needed for a db of every hash and value?
Well "every value" is simply an infinite number.
However to store say every passphrase using printable symbol on a standard keyboard (95) up to a length of 20 would be
95^20 = 3.58 x 10^39 records
If we assume no overhead and an average of 10.5 bytes for the input and 32 bytes for the hash that would be:
1.52 x 10^41 bytes
~152,356,517,023,630,000,000,000,000,000 1 TB hard drives.
The earth has about 1.3x10^50 atoms so even storing 1 bit per atom it would take up roughly a planet sized body. Of course if the user had salt their hash wouldn't exist in your database. To account for every 32 bit salt would require ~4 billion earth sized planets.
So you're saying there's a chance...
LOL +1 "Dumb and Dumber"
PS: Are 25 characters enough for a strong passphrase?
25 random characters is plenty. 25 letter 'a's isn't. There's a range between these two extremes.
Of course, you are correct. That does answer my question though, thanks.
PS: Are 25 characters enough for a strong passphrase?
25 random characters is plenty. 25 letter 'a's isn't. There's a range between these two extremes.
If I understand this correctly, these are all brain wallet addresses?
Mounting a more sophisticated attack could get interesting, but I'm afraid of what I'll find.
Just remember to use strong passwords if you go the "brainwallet" way!
Hey, do go ahead. If you were to find something, it'd be better if we knew NOW rather than later.
PS: Are 25 characters enough for a strong passphrase?
Mounting a more sophisticated attack could get interesting, but I'm afraid of what I'll find.
Just remember to use strong passwords if you go the "brainwallet" way!Hey, do go ahead. If you were to find something, it'd be better if we knew NOW rather than later.
PS: Are 25 characters enough for a strong passphrase?
Ha, we both found SHA256("fuckyou") which TTBit says he funded as an experiment. It looks like I found your other address too -- are you saying you found more that I didn't find, and that you didn't post there?
I was saying that you didn't find any of the ones I found, but I was wrong. I was comparing the transaction IDs you listed with the sha256 hashes I listed. Duh.
Maybe a bit related: How many private keys can a wallet hold in the satoshi client and/or Armory? Millions? Billions? Terabytes? Petabytes?
The reason would be that for serious bruteforcing, one would constantly (for every block on the network) check all your gazillions of addresses if they have been funded - if yes, quickly snatch the money and sign a transaction. To do this though, one would need to iterate over a LOT of data (at least address wise, the block's data could probably be broken down into "address that received money" parts).
The reason would be that for serious bruteforcing, one would constantly (for every block on the network) check all your gazillions of addresses if they have been funded - if yes, quickly snatch the money and sign a transaction. To do this though, one would need to iterate over a LOT of data (at least address wise, the block's data could probably be broken down into "address that received money" parts).
I recently played around with this myself and found that SHA-256("test") has been used: http://blockchain.info/address/1HKqKTMpBTZZ8H5zcqYEWYBaaWELrDEXeE
This answer is pretty thorough and probably correct. The TL;DR is that you're highly unlikely to randomly generate the same private key that someone else has, and picking a rich address and guessing its private key is much much more unlikely. Barring huge advances in computing power or in mathematically breaking the cryptography, everyone's coins are very safe. And, anyone with remotely enough computing power to consider trying to steal coins would make more mining.
And even if you can generate hashes quickly you'd have a hard time querying the blockchain at anything close to that rate. I'm sure that is more a limit than the hashing. (But that's not the same as OP here as he didn't randomly generate hashes) I'd been thinking about trying it out of curiosity for awhile, and last night that curiosity finally overcame laziness. I hacked together a script to SHA256-hash every password in a large (14 million) password leak, compute the corresponding address, and scan the blockchain for transactions touching those addresses (using blockparser.)
I did something similar some months ago and found different addresses that you did:
http://bitcoin.stackexchange.com/a/3170/659
Ha, we both found SHA256("fuckyou") which TTBit says he funded as an experiment. It looks like I found your other address too -- are you saying you found more that I didn't find, and that you didn't post there? I wonder if I could find more with better dictionaries (especially curating entries that bitcoiners might be likely to use.)
BTW, I've since re-run the script searching for transactions using Casascius' deterministic passphrase wallet (something like KeyN = SHA256(String(N)+"/"+passphrase+"/BITCOIN"+String(N)) where N = 1 to infinity for the keys in the wallet) and found nothing, so it looks like anyone seriously using this type of "brainwallet" is picking non-stupid passwords.
So whats the chances of finding some private key? If an uberminer generated hashes non stop and comparing them with the whole block chain what are the chances of him getting a hit?
This answer is pretty thorough and probably correct. The TL;DR is that you're highly unlikely to randomly generate the same private key that someone else has, and picking a rich address and guessing its private key is much much more unlikely. Barring huge advances in computing power or in mathematically breaking the cryptography, everyone's coins are very safe. And, anyone with remotely enough computing power to consider trying to steal coins would make more mining.
So whats the chances of finding some private key? If an uberminer generated hashes non stop and comparing them with the whole block chain what are the chances of him getting a hit?
I once worked out how probable that was. I forget what the exact probability was but it was a number with about one hundred zeros after it.
Assume a 1 in 1e100 chance per hash. You can work out yourself how many billion years it would take to brute force every address, even if you had the hashrate of the entire bitcoin network at your disposal.
I'd been thinking about trying it out of curiosity for awhile, and last night that curiosity finally overcame laziness. I hacked together a script to SHA256-hash every password in a large (14 million) password leak, compute the corresponding address, and scan the blockchain for transactions touching those addresses (using blockparser.)
I did something similar some months ago and found different addresses that you did:
http://bitcoin.stackexchange.com/a/3170/659
I have generated the private keys for all of the 8 addresses listed, by taking the SHA256 hash of passwords from a password list.
Is the SHA256 hash easier to break than MD5?
Thanks...
I have generated the private keys for all of the 8 addresses listed, by taking the SHA256 hash of passwords from a password list.
Is the SHA256 hash easier to break than MD5?
I have generated the private keys for all of the 8 addresses listed, by taking the SHA256 hash of passwords from a password list.
Is the SHA256 hash easier to break than MD5?
Just theorizing but I think most password requirements are worthless and are checking the wrong thing.
Personally if I had a site I would
a) use bcrypt which ensures passwords of 8 characters or more can't be brute forced
b) require passwords to be 8 characters
c) lookup user's attempted password against db of known/weak/leaked passwords and reject it if found.
No need for "Th!s is my @nnoyingly l0ng password333".
"happy clown jumper" all lower case can't be brute forced if protected by bcrypt and isn't on any password list used by hackers.
Personally if I had a site I would
a) use bcrypt which ensures passwords of 8 characters or more can't be brute forced
b) require passwords to be 8 characters
c) lookup user's attempted password against db of known/weak/leaked passwords and reject it if found.
No need for "Th!s is my @nnoyingly l0ng password333".
"happy clown jumper" all lower case can't be brute forced if protected by bcrypt and isn't on any password list used by hackers.
TheirChildrensMiddleNames
Probably a stupid question but how much space would be needed for a db of every hash and value?
3.123 * 10^87 gigabytes. More storage capacity than the NSA has.If your number is right, that's not simply "more capacity than NSA has". That's more gigabytes than some estimations of the number of atoms in the known universe.
We can't store information at the sub-atomic level yet? Scientists be slackin'.
Probably a stupid question but how much space would be needed for a db of every hash and value?
3.123 * 10^87 gigabytes. More storage capacity than the NSA has.If your number is right, that's not simply "more capacity than NSA has". That's more gigabytes than some estimations of the number of atoms in the known universe.
Probably a stupid question but how much space would be needed for a db of every hash and value?
3.123 * 10^Edit: My bad. I put an 8 were there should have been a 7.
Just theorizing but I think most password requirements are worthless and are checking the wrong thing.
Personally if I had a site I would
a) use bcrypt which ensures passwords of 8 characters or more can't be brute forced
b) require passwords to be 8 characters
c) lookup user's attempted password against db of known/weak/leaked passwords and reject it if found.
No need for "Th!s is my @nnoyingly l0ng password333".
"happy clown jumper" all lower case can't be brute forced if protected by bcrypt and isn't on any password list used by hackers.
Personally if I had a site I would
a) use bcrypt which ensures passwords of 8 characters or more can't be brute forced
b) require passwords to be 8 characters
c) lookup user's attempted password against db of known/weak/leaked passwords and reject it if found.
No need for "Th!s is my @nnoyingly l0ng password333".
"happy clown jumper" all lower case can't be brute forced if protected by bcrypt and isn't on any password list used by hackers.
Jump to: