(usually i am doing test like this to check program bugs)

i loaded points from 1 to up to 60 bit but there is issue with only one key. very strange guys please load this key and try to search it. (maybe issue is on my side only)

00000000000000000000000000000000000000000000000000001f80f4304a6c 03925fe2c8202a40abd17726f04d448d7c7479fb6f5f2e8f343d8010dc8e86cdee

if you guys also unable to hit than i guess program is missing some hits which is showing that there is bug present in codes (perhaps)

Yes, during the tests, I also noticed that some keys are skipped, but only with a large K value.

but K is not important when there is high range 1:10000000000000000000 with multiple keys are loaded and by the way K was in recomanded range as well. during test keyhunt find all keys from smaller like 1,15, 3f0, 77fc , cc57d up to 60 bit range keys but only unable to find this point , i deleted all -S files and recreated them but still same issue

@albertobsd please review as even one hit miss can be deadly

Yes i know that is the most important thing in the program (Not missing keys), well i will check that specific key and range, any news i will let you know. By the way can you tell us what K value you use even if it is an small one. or also if you change the n value

Thanks for report it.

i just test it with k = 1024 it works:

I will test with others K values, also i will load all the puzzles from 1 to 63 and 65 just to check it

I just test all the puzzles upto 65 with K = 1024 , 6 threads and

please see the command below and i am letting system to auto calculate N and as well specify N but same results.

My test pc is with 16Gb Ram so i am utilizing around 11G with 3 thread's

$ ./keyhunt -m bsgs -B secuential -t 3 -k 563 -r 1:10000000000000000000 -f key -s 1 -S

or

$ ./keyhunt -m bsgs -B secuential -t 3 -k 563 -n 17592186044416 -r 1:10000000000000000000 -f key -s 1 -S

in above both test i load this key (03925fe2c8202a40abd17726f04d448d7c7479fb6f5f2e8f343d8010dc8e86cdee) individual and mix with other keys as well

Keyhunt cannot find only this key in both tests other all keys found by keyhunt.

i just test it with k = 1024 it works:

I will test with others K values, also i will load all the puzzles from 1 to 63 and 65 just to check it

i am sure this will work with reducing K or N value but consider this as well

if you increase the range from 1:10000000000000000000 , K and N only matter if they are not according to define table.

but i am using K and N with in Max range and plus i load smallest key like 1 and 11 and 2c0 , 2f , 1f. but all keys were found with out any issue but only this key is not found by keyhunt ~ not sure whats going on

thank you, i will solve this issue, let me test and debug the program with you values, maybe solving this i will solve all the issues related to the K parameter.

Thanks!

thank you, i will solve this issue, let me test and debug the program with you values, maybe solving this i will solve all the issues related to the K parameter.

Thanks!

Thanks bro hope you will fix this 👍 💯 🥇

Please note that number of threads was setting to 6 but only 4 threads were used, this is because the range 63 bits is small for BSGS and we only need four times the current N value to fill it, to avoid this we can use a smaller N value but with some multiplier K in that way w we can achieve the same speed and also be able to launch more threads. Repeat only in case that the range was small like this.

Please note that number of threads was setting to 6 but only 4 threads were used, this is because the range 63 bits is small for BSGS and we only need four times the current N value to fill it, to avoid this we can use a smaller N value but with some multiplier K in that way w we can achieve the same speed and also be able to launch more threads. Repeat only in case that the range was small like this.

its not a issue as you can set sequential search mode & increase the range 1:1000000000000000000000000000000 something like this and than use bigger K and N but 100% BSGS should not skip this key. but strangely BSGS get all the keys from smaller than this and also bigger keys than this but not this one. That is strange thing to me and never happened before.

С к 128 находит

yap i am also not hitting , very strange indeed

Ok guys i need to clarify that this is a bug, missing keys is a critical bug, the program lose all its sense with that kind of bug:

I try to delimitate the range to know in a practical why it is missing that key, I'm using this command now:

./keyhunt -m bsgs -t 3 -k 563 -n 17592186044416 -r FC07A182536:1FC07A182536 -f key -s 1 -S

The program ends almost immediately without found the key, but why, the key is there?

Well I found some strange behavior with some variable, technical stuff apart, I FOUND the bug and SOLVED it.

now the command that you use work perfectly for all puzzles from 1 to 63 and 65

time ./keyhunt -m bsgs -t 3 -k 563 -n 17592186044416 -r 1:10000000000000000000 -f key -s 1 -S

Output:

[+] Version 0.2.211024 Chocolate ¡Beta!, developed by AlbertoBSD
[+] Threads : 3
[+] K factor 563
[+] Stats output every 1 seconds
[+] Mode BSGS secuential
[+] Opening file key
[+] Added 1 points from file
[+] Range
[+] -- from : 0x1
[+] -- to   : 0x10000000000000000000
[+] N = 0xfff7ec00000
[+] Bloom filter for 2361393152 elements : 8094.58 MB
[+] Bloom filter for 118069658 elements : 404.73 MB
[+] Allocating 1801.00 MB for 118069658 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_2361393152.blm .. Done!
[+] Reading bloom filter from file keyhunt_bsgs_5_118069658.blm .. Done!
[+] Reading bP Table from file keyhunt_bsgs_2_118069658.tbl .. Done!
[+] Thread Key found privkey 1f80f4304a6c
[+] Publickey 03925fe2c8202a40abd17726f04d448d7c7479fb6f5f2e8f343d8010dc8e86cdee
All points were found
[+] Thread 0x2ffe7c400001
real    1m19.324s
user    1m15.405s
sys     0m3.924s

All points were found

This in theory will solve all the missing keys for all the K values, but please do you test before and report any missing key.

let me test it please and will get back to you , because K and N should not be matter and what ever K and N i will use (ofcourse i will increase range with bigger K and N) but this should never miss any hit.

@albertobsd stunning bro 💯

issue is resolved i loaded different keys on different points between 1:60 bit and all were found with different K and N with out any issue. this version is stable in BSGS mode not sure about other modes. i am going to close it with big thanks to @albertobsd