Topic: How much time to crack a private key? - page 2. (Read 5539 times)

Lolz.  I got to remember that next time Burt.

ty!

Very cool. Thanks.
Will phone back if I find any coin in the deep space.

Heck with all this hard maff stuff.  You can determine how long it will take just by doing it!

1) Go to this thread:  https://bitcointalk.org/index.php?topic=107172.0;topicseen
2) Download the program
3) Enter all the public keys from this thread:  https://bitcointalk.org/index.php?topic=92423.0;topicseen
3) Run the program
4) Report back here when you crack one of the richest keys!

2¹⁹² is the approximate thermodynamic limit of how high a perfect computer could count if it could capture and use up all the energy that the sun will ever produce (leaving nothing for life here on earth).  It is used as an example to demonstrate just how large of a number we are talking about here.  The actual number of possible private keys is a bit less than 2²⁵⁶, demonstrating further how difficult a brute force attack is since 2²⁵⁶ is so much larger than 2¹⁹² which uses all the energy the sun will ever produce.

In actuality, there probably isn't a need to iterate through that many private keys.  The bitcoin address space is only 2¹⁶⁰ from the RIPEMD-160 hash that is used.  If we can assume that RIPEMD-160 results in an even distribution of addresses, then the number of iterations needed to encounter a collision will be much less than if the address space was 256 bits.  However, we are still talking about a number that is large enough to consider it futile to attempt.

Waste of time trying this..

I am not sure why some of you say 2^192 and some say 2^256

assuming 2^192

p=1-(2^192/(2^192-1))^n

where

p = probability to find a key in 1 iteration
n = selected key space (the addresses with balance > 0

so
q=1-(1-(2^192/(2^192-1))^n)

q= probability of not finding a key in 1 iteration

j= number of iterations

P=1-(1-(2^192/(2^192-1))^n)^j
P= prob of find a key in j iterations

can someone find the j value to satisfy =
q=0.5
q=0.1
q=0.01
q=0.001
q=0.0001?

It depends a bit on the situation.

Imagine for a moment that it takes 10 ms to calculate the address from a given private key.
Imagine also that it takes 0.1 ms to look up that address in a database to see if it is a match.

Calculating 10 iteration of private keys and looking up 1 address each time is (10 x 10ms) + (10 x 0.1 ms) = 100 ms of calculation time + 1 ms of lookup time = 1001 ms
Calculating 1 iteration of private key and looking up 10 addresses is (1 x 10 ms) + (10 x 0.1 ms) = 10 ms of calculation time + 1 ms of lookup time = 11 ms

No, it will take more time.

If it takes 1 second to make one attempt to crack one address, then making one attempt to crack 10,000 addresses will presumably take 10,000 seconds.  I can't see why making one attempt to crack two addresses would be quicker than making two attempts to crack one address.  Because you have to make more checks for more addresses, unless there's something I'm misunderstanding.

Yep, it limits it to just a bit less than 2²⁵⁶ possible combinations.  Not infinite, but a large enough number that it doesn't matter that it isn't infinite.

Pay closer attention. He's talking about counting from 0 to 2²⁵⁶.  Just counting.  No encryption, no algorithm, no hashing, just counting.

If it is impossible to count to 2²⁵⁶, then clearly it is much more difficult than impossible to actually "crack" a private key via a brute force attempt regardless of whether you are attmpting to "crack" AES, Asymetric, or a simple hash.

Also note that as long as the address hasn't been used to send any bitcoins yet, the public key is unknown, so it isn't enough to brute force ECDSA to find out if the private key is associated with some bitcoins. For each iteration of the brute force attempt you would need to calculate the public key via ECDSA, and then calculate a SHA256 hash, and then calculate a RIPEMD hash, and then compare the result to a list of addresses that have bitcoins in them.

Human minds have a very difficult time comprehending VERY LARGE numbers.  The fact that you are comparing to 1,000, or 10,000 or even 10,000,000 addresses isn't going to make the brute force attempt possible.

It "limits" it to an insanely large number.  A number so large that our star doesn't have sufficient energy reamining to COUNT to 2^256 much less brute forces keys.  Note: this assumes you could build a perfect computer (in the thermodynamic sense), capture the entire energy output of our star (and exterminate all life on our planet in the process), convert that energy with no loss, and build a large enough computer to use that energy, and keep the computer at roughly the background temperature of the universe (perfectly radiating waste heat).  If you did all that you could count to ~2^192 which is about 1/Quintillion of 1% of the way to 2^256.

So the answer is ... no.

However there are some non-brute force attack which (someday) may lead to an exploit.

1) If there is a bias or flaw in RNG that can be exploited it in theory could allow an attacker to narrow the search space.  By knowing the creator didn't use a range of numbers you can exclude them from the search and potentially brute force a much smaller keyspace.  Then again narrowing the search space from 2^256 to 2^190 doesn't really do you any good, even narrowing it down to 2^128 wouldn't be viable.  Still it is a theoretical exploit.  With true hardware and even quantum RNG becoming cheaper and accessible this may not even be possible in the future.

2) If a flaw is discovered in SHA-256 or RIPEMD-160 it "could" allow a faster than brute force attack attempting to force a collision.  The bad news is such flaws tend to take decades to develop from academic curiosity to real world attack vector.

3) Quantum computing potentially could make faster than brute force attacks on ECDSA a reality ... someday.  It would take an huge number of quibits (magnitudes beyond anything we can do today) to make it possible.  This also requires you to know the public key which remains a secret until coins are spent.  Of course funds could be moved to quantum resistant algorithms rendering this attack void.

So? I am sure someone come up with an answer.

If i have to crack the private key of a specific address it will take more time than I can care about. But I am asking how long to crack any of the thousands of address with possitive balance.

That should be much more easy.

If there are 2 people in a room the prob. of the 2 people with the same birthday is like 1/365 but if i have 23 in a room the prob of 2 of them having the same birthday is 50,7%

Si the time consumed to someone finding someone's private key should be way to shorter than the age of universe

The question is how much shorter?

I mean that the attack would be easied by the fact that a private key is made of a known, exact number of characters (34 I think), not one more, not one less. That limits much (compared to infinite) the number of possible combinations to test.

He's talking about 256 bit AES keys here, not Public/Private key pairs.  Asymmetric keys are weaker than AES keys in general (which is why they need to be much larger).  I'm not familiar enough with ECDSA though to make a judgement about key strength for bitcoin key pairs in particular.

I don't understand your comment. If you assume that private keys are NOT totally random (i.e. uniformly distributed), then it's not a brute force attack. I don't know how you can assume that though.


I didn't know he was into metaphysics.

P.S. I don't think anyone with a bit of sanity ever made such a prediction.

Ray Kurzwiel has made futurist predictions but never saw the one about

ie about 60 years from now.

Edit: if you believe Ray Kurzweil

Only two characters. It is entirely made up of ones (1) and zeros (0), but there are 256 of them.


That is what the definition of "brute force attack" is, isn't it?

I missed them. However a brute force attack would be much easied by the fact that the private key is a known number of characters. Moreover it would even not have to be really a brute force attack based on power of calculus, but just a check of the greatest number of possible private keys in the shortest time possible.