@WP
I take a 255 bit pubkey, divide it by 33. Now I only have to search the 2^255/33 ~ 2^252 range to find the key. What a reduction.
@ssxb
Well but what is the new knowledge?
Also the 33 division makes sense as the distance between each point will be the mod inverse of 33 or so. Its like cutting the whole N into ranges, as mentioned before. Only problem is, that you are only getting one in the lower bruteforcable range and then can jump from that one and can determine the other 32 private keys.
And yes, you just have to multiply the privatekey times your divisor and then mod N to get the right result.
Again, reduction of range, not what I am saying. I also said you can use any divisor, not just 33. For tests, I also did 192, and 192*192.
Everyone keeps saying you add a bigger range/create a bigger range, but that is not the case. If you divide by using whatever divisor, it does not create a larger keyspace to search. All ranges to search are the original size of whatever size the original private key range is in, except the original range, it has obviously been reduced. So if you start with a key that lies in a 120 bit range and divide by 192 or 256 or 1,000,000, then you can find any pubkey in the same size range. You do not make search range larger.
Also "2^255/33 ~ 2^252" I do not know where this math comes from. If I take a key in a 2^255 range and divide by 33. 255/33, then the new reduced range would be at least 250, but again, not the point here.
"multiply the privatekey times your divisor and then mod N to get the right result" -- seems like more steps than needed, I do not mod N anything to jump back to the private key but I imagine there are multiple ways to walk back to original private key...9 ways to skin a cat.
