65-bit, after 5 minutes I killed it, or else it's just a lost day.
Is this like a biggest dick competition, to randomly put stuff like "Tera" or "Exa" in front of the "keys/s", even though that would only be possible if running on a machine with thousands of TERA-hertz processor?
I will add "QuettaKeys/s" in my code.
python kangaroo.py -keyspace 10000000000000000:1ffffffffffffffff -p 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b
[+] Starting CPU Kangaroo.... Please Wait Version [ 15112021 ]
[+] Search Mode: Range search Continuous in the given range
[+] Working on Pubkey: 0430210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1be383c4a8ed4fac77c0d2ad737d8499a362f483f8fe39d1e86aaed578a9455dfc
[+] Using [Number of CPU Threads: 19] [DP size: 10] [MaxStep: 2]
[+] Scanning Range 0x10000000000000000 : 0x100ffffffffffffff
[+] Scanning Range 0x10100000000000000 : 0x101ffffffffffffffs][Dead 3][RAM 92.8MB/45.5MB]
[+] Scanning Range 0x10200000000000000 : 0x102ffffffffffffffs][Dead 3][RAM 94.4MB/45.5MB]
[+] Scanning Range 0x10300000000000000 : 0x103ffffffffffffffs][Dead 2][RAM 98.3MB/45.5MB]
[+] Scanning Range 0x10400000000000000 : 0x104ffffffffffffffs][Dead 6][RAM 91.7MB/45.5MB]
[+] Scanning Range 0x10500000000000000 : 0x105ffffffffffffffs][Dead 1][RAM 91.4MB/45.5MB]
[+] Scanning Range 0x10600000000000000 : 0x106ffffffffffffffs][Dead 3][RAM 91.3MB/45.5MB]
[+] Scanning Range 0x10700000000000000 : 0x107ffffffffffffffs][Dead 5][RAM 91.1MB/45.5MB]
[+] Scanning Range 0x10800000000000000 : 0x108ffffffffffffffs][Dead 4][RAM 91.3MB/45.5MB]
[+] [10981.32 TeraKeys/s][Kang 19456][Count 2^29.53/2^29.09][Elapsed 16s][Dead 1][RAM 62.1MB/45.5MB] ^C
Perhaps my mistake is, that I set to use the parameter
-n as default 2**56.
In fact it was designed in this way for those who are not considering to scan the whole range. Let's say searching from
A to B you could search
smaller chunks of each 56bit range with moving randomly/sequentially overall. Otherwise even if a Key is in the beginning of the range but the collision will not happen untill we have sufficient numbers of Tame and Wild kangaroos. With chunks range searching if the Key happens to be within that smaller chunk, you will find it.
Anyway for any Key searching in the range of 1 to 66 bit Key
we could use -n = 18446744073709551615 to bypass this approach.
Also specifically for smaller Keys between 1 to 66 lets say
-ntu option could be usefull. We can perhaps set the dp = 16. Then we could first run the Kangaroo using 66puzzle and
option -ntu removed and this will run and save the Tame kangaroos into a
file HashTable.ice. This can be run several times and when you have couple of GB file then.
Next time while you are actually searching for Any Puzzle in similar range then you will have more numbers of Tame Kangaroos precomputed which will help in the collision faster.
Another allegation about the Display Keys/s is again not the operations/s but roughly the range coverage speed based on the probability of success using 2.08*sqrt(range) operations. There is already Count and Elapsed.
Nothing new about pre-computing Tame DPs. I said this before, Tames can be precomputed in advance, in absence of the Public Key. And Wilds need to come into action after that. Lucky for whoever listened. Maybe now some guys understand why I can crack any 66-bit key in a couple of seconds instead of half a minute.