Topic: Pollard's kangaroo ECDLP solver - page 26. (Read 59389 times)
There is already a small python script for your needs here in this thread.
Take the privatekey of 4. Half it, you get 2. Take the privatekey of 5 you get 2.5. 2.5 means, 2 + N/2. To get the "half" you subtract 1 and then halve it and get 2.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
any c language script for halve pubkeys with input file ( pubkeys) and output file ( pubkwys) ( for linux )So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
example
./halve -i inputfile.txt -o output.txt
So halve -i input.txt divide by 2 = -o output.txt ?
Take the privatekey of 4. Half it, you get 2. Take the privatekey of 5 you get 2.5. 2.5 means, 2 + N/2. To get the "half" you subtract 1 and then halve it and get 2.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
any c language script for halve pubkeys with input file ( pubkeys) and output file ( pubkwys) ( for linux )So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
example
./halve -i inputfile.txt -o output.txt
So halve -i input.txt divide by 2 = -o output.txt ?
Take the privatekey of 4. Half it, you get 2. Take the privatekey of 5 you get 2.5. 2.5 means, 2 + N/2. To get the "half" you subtract 1 and then halve it and get 2.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
any c language script for halve pubkeys with input file ( pubkeys) and output file ( pubkwys) ( for linux )So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
example
./halve -i inputfile.txt -o output.txt
So halve -i input.txt divide by 2 = -o output.txt ?
notatTether posted a python Script some time ago. But i also have a Javascript Version of it, which can be made to be an standalone executable. interested?
Definitely. Compiled Node is much faster than any Python script I can throw at here.
How did you make it?
notatTether posted a python Script some time ago. But i also have a Javascript Version of it, which can be made to be an standalone executable. interested?
Take the privatekey of 4. Half it, you get 2. Take the privatekey of 5 you get 2.5. 2.5 means, 2 + N/2. To get the "half" you subtract 1 and then halve it and get 2.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
any c language script for halve pubkeys with input file ( pubkeys) and output file ( pubkwys) ( for linux )So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
example
./halve -i inputfile.txt -o output.txt
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
Oh you just use public keys.
Just change the nkeys variable at the top to be the number of keys you want to receive (and make sure bits_toinspect is greater than or equal to log2(nkeys).)
That's equivalent to knowing the very lowest bit of the private key so you've effectively reduced your search range by a power of 2 e.g. 2^60 --- 2^59. It's not useful enough in a practical setting though. Not to mention there isn't a foolproof way to guess the private key's parity in the first place.
Do you have an example of that?
Example of which one? You are quoting two different problems here. The latter one is "how to guess the lowest bit of all PKs with 100% confidence" which is impossible to do.
Take the privatekey of 4. Half it, you get 2. Take the privatekey of 5 you get 2.5. 2.5 means, 2 + N/2. To get the "half" you subtract 1 and then halve it and get 2.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
So if you can determine if the lowest bit is 0 or 1 you can half it properly. But there is no method to determine 0 or 1. Thats why you can theoretically halve multiple times but have to use the false keys. Like you take a big number with 2^120 bit, and can halve it and get two keys were you know one is 2^119 and one is "wrong". Use both keys and halve them. You know one is 2^118 and three are false. Take those four keys and halve them again, one is 2^117 and 7 are false.
So you get exponentially more keys each halving. Which is useful for e.g. 2^60 as you can get 2^45 with 2^15 (15 times halved, you can do more halvings if you like) potential keys to check in very few minutes. But you can not do it with 2^120 as you still get 2^105 range with 2^15 keys, which takes still a long time to crack. Doing 2^120 halvings is basically bruteforcing the key.
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
Oh you just use public keys.
Just change the nkeys variable at the top to be the number of keys you want to receive (and make sure bits_toinspect is greater than or equal to log2(nkeys).)
That's equivalent to knowing the very lowest bit of the private key so you've effectively reduced your search range by a power of 2 e.g. 2^60 --- 2^59. It's not useful enough in a practical setting though. Not to mention there isn't a foolproof way to guess the private key's parity in the first place.
Do you have an example of that?
~
Bro, Hello.
How to check only 1,2,3 pubkeys with this scrypt ? Without random ganeration, and without many publick keys ?
Thx
By placing just the 3 public keys in input.txt file and adjusting the "nsamples" (or maybe it was called "nkeys") parameter in the script to be just 1,2,3 or like that, to print that many divisions per key.
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
At the moment it is impossible to find a 256 bit private key, it takes thousands of the most powerful GPUs and a lot of time.
That's not even close. It takes more than a quintillion of the most powerful GPUs running for 1000 YEARS to find a single 256 bit private key. And that is with Kangaroo/BSGS methods.
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
At the moment it is impossible to find a 256 bit private key, it takes thousands of the most powerful GPUs and a lot of time.
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
Oh you just use public keys.
Just change the nkeys variable at the top to be the number of keys you want to receive (and make sure bits_toinspect is greater than or equal to log2(nkeys).)
Does it have any REAL value other than purely statistical?
Yes, provided I can figure out how to jump from one low std. deviation key to the next without pregenerating them all. [and without too much computational increase from addition].
I have a newbie question.
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
When gpu is used either for bsgs or kangaroo how many % of gpu power is used? Because if I am not wrong common gpu has got hundrets to thousands cores but over here in forum I could see examples running just a few threads on gpu? How is it? What is the principle for gpu usage? Each core mskes exactly the same task just for different interval?
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
When gpu is used either for bsgs or kangaroo how many % of gpu power is used? Because if I am not wrong common gpu has got hundrets to thousands cores but over here in forum I could see examples running just a few threads on gpu? How is it? What is the principle for gpu usage? Each core mskes exactly the same task just for different interval?
GPU cores get dozens of smaller ranges loaded in them at once, these get searched quickly so that they can be loaded again, that's why GPUs are much faster than CPU.
I have a newbie question.
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
When gpu is used either for bsgs or kangaroo how many % of gpu power is used? Because if I am not wrong common gpu has got hundrets to thousands cores but over here in forum I could see examples running just a few threads on gpu? How is it? What is the principle for gpu usage? Each core mskes exactly the same task just for different interval?
If I need to find just one private key somewhere in 256bit space does it have a meaning to use gpu? Or cpu is enough?
When gpu is used either for bsgs or kangaroo how many % of gpu power is used? Because if I am not wrong common gpu has got hundrets to thousands cores but over here in forum I could see examples running just a few threads on gpu? How is it? What is the principle for gpu usage? Each core mskes exactly the same task just for different interval?
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
Oh you just use public keys.
Just change the nkeys variable at the top to be the number of keys you want to receive (and make sure bits_toinspect is greater than or equal to log2(nkeys).)
Does it have any REAL value other than purely statistical?
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
Oh you just use public keys.
Just change the nkeys variable at the top to be the number of keys you want to receive (and make sure bits_toinspect is greater than or equal to log2(nkeys).)
What does Std. Deviation: 1.1902380714238083 mean?
That it's likely a human-generated private key.
The standard deviations start from 0 to just over +-1, where +-1 (and above) mean that the key is definitely human-generated and 0 means it's definitely computer-generated.
None of the keys have std. deviation = 0 because you can never be quite sure whether a computer really did generate a key. But at low std. deviations you can be sure that the private key resembles as much as a random private key as possible.
Do you put a private key or public key in the input.txt because I used 1 public key. When I ran the script it gave me just 1 public key.
What does Std. Deviation: 1.1902380714238083 mean?
That it's likely a human-generated private key.
The standard deviations start from 0 to just over +-1, where +-1 (and above) mean that the key is definitely human-generated and 0 means it's definitely computer-generated.
None of the keys have std. deviation = 0 because you can never be quite sure whether a computer really did generate a key. But at low std. deviations you can be sure that the private key resembles as much as a random private key as possible.
Jump to: