Your Q that you have just linked to says this:
guys lets say 32 divisors will return 32 keys , one of will be guaranteed for lower range but what about other all keys , i guess they all are also valid ~~ so my question is all other keys are random in 256 range or what?
Emphasis on "in 256 range"
This is what I reverse-engineered a month ago for someone who thought they can reduce 120-bit keys a N number of smaller keys, where N is a tiny number like 260:
https://gist.github.com/ZenulAbidin/e8687d9e16189c99d192e97d37e71dbeAs you can see, this exactly reproduces the results of the post I quoted.
Start with this public key 03bb2228d3ea32cb3c1eb160cc824a4ba8115f9a7f415d18ddcaac8193defc2c47
Divide it into 32 "zones", where the first zone is from f7fffffffffffffffffffffffffffffec4d965ff79ce5b39e1d3cb9869b48f37 to effffffffffffffffffffffffffffffecf03ef184454163803d538a40332dd2d (this script spits it into two ranges so that you can actually load this into brute force programs).
Now you see the problem with this?
The generated range is already much bigger than the input range. (same for the other 31 zones - which all match your test output BTW). Instead of a <120-bit range now we have to do an impossible 256-bit search!
A script that reduces keys is supposed to make the range smaller, currently, the only known script that does this is the one by
iceland.
And it does that well (at the expense of making an unmanageable amount of keys).
Now here's a method for reducing PKs (by guessing which ones are more likely to be the correct one) that actually reduces the range in the process - in fact it can be used to generate the most likely N keys (where N is any positive number - larger N = higher probability obviously):
You see, the number of keys you get from this can be
drastically reduced not by splitting them up into "zones", but by using statistical analysis to see what bit patterns in OpenSSL private keys are more likely to appear in. Using birthday paradox, certain combinations of the private key bits account for a large percentage of the probability - and most importantly
the lower PK bits can be used as an index to the array of millions of PKs generated (say length M) - because all of the divided pubkeys have been subtracted by M first.
Example:
I divide Public Key XYZ by 32 - this makes 32 public keys with each of them have been subtracted with numbers 0-31 first before dividing.
Say the results are: A, B, C, D, E, ... etc.
Put all of these in an array so that there are 31 elements in it.
Now you randomly generate about 1000 private keys using OpenSSL (Because let's face it, the puzzle creator would've found it convenient to create hex private keys only from OpenSSL command line) and measure how frequently the 1 and 0 bits appear in the lowest ceil(log2(32)) = 5 bits.
Then you use that info to create a table of the most frequent (likely) lowest ceil(log2(32)) = lowest 5 bits.
Now the kicker here, is that instead of using them as a guess for the PK,
you use them as a guess for the index.
That is because when a private key is found, you will multiply it by 32 -
and add the remainder back to it to get the same lower bits as in the frequency analysis.
Therefore, the index numbers directly correlate to the lower bits of the actual private key. And this is why this method works (script is not finished yet I'm still working on it).
Again, the problem with your method is that it makes the range
bigger than what we started with in the first place.
So please make sure methods you make actually reduce the range before misleading people about them in the whole thread.
. So as I wrote earlier, this bitshifting is a memory/processing performance tradeoff. The more you bitshift the more keys you have to check, till it is not practical anymore. So e.g. you could store 2^30 pubkeys into a bloom filter and need about 4 GB memory or 2 ^31 pubkeys and about 8 GB RAM or 2 ^32 pubkeys and about ....
