Topic: Private Key cracker apparently demonstrated (Read 9599 times)

It's a good reminder to only generate addresses using "reliable" methods.  EK could buy out the top google listing for bitcoin paper wallet and replace its RNG with his own fake RNG.

Obviously, once you change the group from multiplicative to additive it won't be an exponent anymore But in the end, it's all just notation, the concept is exactly the same.

Don't confuse the DLP with the ECDLP, though. Similar concepts, but ECDLP doesn't use exponents (it uses EC multiplication instead, which is the operation that is intractable).

Q is public key, n is order of G, set m = sqrt(n)

Baby-step (i) Giant-step (j) is then to find a collision: 

i*G = Q − jm*G

or, in other words, find the sum of two points, i*G + jm*G, that collide with the public key point Q that you're trying to solve. The private key will be i + jm (mod n).

that's in the exponent, which is an integer - A^x = A^(im+j) = A^(im)*A^j, if you will.

...x = i m + j

I count two.  The group operation was previously defined as the multiplication... 

Two operations? It only has one, multiplication.

It seems to me EK has simply shown us something we all already know.

If there is a weakness in the random number generator used to generate the private keys and this RNG weakness is known or can be determined then the search space for the public key -> private key problem can be reduced.

All EK has done is prove that given public keys calculated from private keys generated by his personal totally bogus non-RNG (NRNG^TM) he can easily recover the private keys.

EK:  A bit of advice.  You published your program too soon.  It would have not been that much more work and would have been a lot more convincing if you had taken the time to do the hashing in your program so that you could show it "cracking" Bitcoin addresses.  You also made the mistake of trying to sell it here in a forum filled with people that know more about cryptography than you do.

Next time add the hashing and pitch your wares on a less technical forum.  Here is a pitch that might work for you (somewhere else, not here):

The maths well exceeded my comprehension. It seems the approach is a "hit and miss and aim again".
Could it be summerized as "possible but improbable"?

Whether the cracking scrypt works or not...
At least OP has stated that address is safe when the public key is not broadcasted,
thus confirming reusing addresses is not safe, this is all I need to know.

Random means "no pattern," by definition.

You could question whether addresses are truly being generated randomly, but you can't question whether addresses that are ex hypothesi random might actually have a pattern - at least not without falling into incoherence.

Well, I do think if one is not savy or paying attention they would misunderstand what he is saying - yes this will mislead many.  But then he also said if you're not savy, and don't know what you're doing this isn't for you.  Yes he's a salesman, but he's not scamming... just an interesting word choice and provocative, tabloid-ish title.

The current title of his thread is:  "[WTS] OpenCL Based, Optimized BTC Private-Key Cracker with Sources [WITH VIDEO]"

The first post says things like:


The only thing in the first post of that thread that indicates that this isn't what people think it is, is the following:


Which is incredibly confusing, but alludes to the fact that the program only works on special keys that no one is likely to ever find in the wild.

So, if all that isn't misleading, I don't know what is.  I guess if what he's doing is acceptable, I might as well sell my "OpenCL Based, Optimized BTC Miner with Sources, 10 TH/s".  It works with any SHA-256 Proof of Work (however they are all special-weak)!  You could crack that 10 MILLiON US$ chain of blocks!

The paradox here is that if someone has broken ECDLP and obtains the keys to the kingdom (BTC and all of the other crypto coins that rely on ECDSA), and they go public with it, then they will assume ownership of nothing because the currency would cease to have any value.  

Does this mean that ECDLP remains unsolved?  Not necessarily.  There are attacks based on randomly finding collisions in the EC space in order to derive unknown variables in the algebraic space (Pollard Rho and Kangaroo come to mind), and a clever person may have figured out ways to make this more efficient, or at least less random in nature.  Hopefully, they remain clever and not seek fame or attention.

In this case, though, I agree that it appears the script on GitHub is being used as a vehicle for a distributed search for the private keys that generate well-known public keys... or similarly, a search for "k" that results in a well-known signature R value (which can then be used to derive the private key for the public key used by that signature).  

http://en.wikipedia.org/wiki/Baby-step_giant-step

What? Why does this "cyclic group" appear to have two operations? This is invoking the ring structure I guess?

Sloppy article!

Evil can't (and never said he could) crack fair keys.  He has shown something subtly different.  Nobody should be afraid, nor do I think he could be called a scammer for selling software, unless he is lying about something.

So he wrote a script to generate a (relatively) small and predictable number of keys that he then "cracks" to prove his program works.  Of course because the number of keys that he can crack is something like 1/1e39 of the number of possible keys there's literally no chance he can crack an address that has anything in it to steal.  So instead he sells his program for 2 BTC, if he even sells 1 copy then he'll have more BTC than if he had actually used his program.

You're basically breaking ECDSA, claiming that privkey-to-pubkey transition results in a non-uniform distribution.

The crappy and super slow implementation of ECC arithmetic linked to on that website checks keys generated against a couple thousand 32 bit values. (Why use a slow thing like that if you've supposedly got some amazing gpu thing). My guess was that he's using this as bait to get people to run that program and the values that its looking for are all 'near' high value keys.

Or other wise it just another lame market manipulation attempt. Either way, ... if he actually can crack something I welcome him to go solve any of the 200,000 keys I listed and collect his bounty.

Thanks for decoding his JS, I'd just ignored it.

Here's what's going on.  Evil-Knievel has pre-computed a couple points on the secp256k1 curve.  Specifically points where the exponent is of the form 2**N. (see 1,2)  He then wrote a program, the "cracker", that can search the area around those points.  If a Bitcoin key-pair lies close to one of those points, his program will find it.

This isn't dangerous.  It's improbable (~impossible) that any uniformly random Bitcoin key-pairs are weak to his pre-computed points.  The secp256k1 keyspace is, for all practical purposes, infinitely large.  It doesn't matter if Evil-Knievel had a gabillion-gajillion pre-computed points and all the computing power in the universe.  His approach still wouldn't crack a normal Bitcoin key-pair.

To me, having just read Evil-Knievel's thread, it sounds like he's insinuating that there is danger here.  He's insinuating that a uniformly random Bitcoin key-pair has a reasonable chance of being tractably close to one of his pre-computed points.  There is no reasonable chance of this, and his claims are ridiculous.  The thread should be closed as a scam, because he's asking for money on misleading premises.

If he has nothing to hide, why was his HTML generator obfuscated?  I'll help and de-obfuscate the generator for everyone.  Here's the algorithm:


See the problem?  He just needs to take a generated public key, add G to it ~20,000,000 until it matches one of the 128 pre-computed keys (which are of the form 2**N), and BAM the private key is "cracked".  This doesn't make Bitcoin weak.  It never will.  It's a rainbow table attack.  But mankind will never have enough computational and storage power to make rainbow tables work against secp256k1.

As for the bitprobing.com "project".  That's a load of bollocks.  If you don't believe what the experts have to say about ECDSA, that's fine.  But go learn group theory and number theory first, before asking the public to help run unsubstantiated "experiments."


I know these forums are intentionally soft-modded, and appreciate that to an extent.  But it's times like these I wish the forums were more aggressively moderated so that Evil-Knievel could just be banned for misleading and scamming people.


(1)  Actually, he fscked this up.  He interpretes the decimal result of 2**N as hexadecimal.
(2)  2**128 is 340282366920938463463374607431768211456.  Interpret that as a hexadecimal private key and you get a public key of 04864f29af3191e135f5c78499271961f2313110fb2a296bf072733475529da1fb4d5cef64d1212 a946775bfb2db5319fb618089ae8806d618f44d68d3bdb18650.  The least significant 32-bits of the X coordinate is 0x529da1fb.  That matches one of the constant in his script.  I assume the rest match similarly.

If it's the kind of address public key his program is searching for, sure. However the chances of any real-life addresses that have coins in it falling into that range are abysmal.

So , I generate an address , send him the private key and then he can crack it? =))))))))))))0

Ah, I see, my apologies.

edit: he's saying the addresses need to be "generated completely as to the manual" though... I'm pretty sure that means being close to the step in his baby-step-giant-step algorithm he's using.