Keyhunt - development requests - bug reports

[SlaitX]

@SlaitX

I wrote the binary bloom filter update for Keyhunt. Hit me up if you have any issues or questions.

Great job. But I tested your version.
I have also already solved the problem with the fuse filter and added an XOR filter as well. The most memory-efficient is undoubtedly the fuse filter. It saves more memory.
For large filters of 256 GB, I implemented a file-based version of writing all the points, which is why the formation of this filter takes a long time. I need to study your code to understand whether you have solved the problem of forming three filters or not. Because the FUSE filter requires all the points in memory or splitting them into packets.

Regarding the differences between the versions.

Alberto's version
./keyhunt -m bsgs -f test.txt -r 8aa15e21125e3806:9fa15e21125e3806 -k 64 -S -s 1 -t 16
Thread 0x8e0ede21125e3806 s in 14 seconds: ~17 Pkeys/s (17494172436454253 keys/s)


Punk_design version
./keyhunt -m bsgs -f test.txt -r 8aa15e21125e3806:9fa15e21125e3806 -k 64 -S -s 1 -t 16
Thread Key found privkey 90e15e21125e3806 ~20 Pkeys/s (20406935811522560 keys/s)

My version
keyhunt -m bsgs -f test.txt -r 8aa15e21125e3806:9fa15e21125e3806 -k 64 -S -s 1 -t 16 -x fuse
Thread 0x90d6be21125e3806 | [446841525528166400 keys][14 sec][~31 Pkeys/s (31917251823440457 keys/s)]

Even the Bloom filter version has a faster speed.
keyhunt -m bsgs -f test.txt -r 8aa15e21125e3806:9fa15e21125e3806 -k 64 -S -s 1 -t 16 -x bloom
Thread 0x8e9f5e21125e3806 | [287139660616957952 keys][11 sec][~26 Pkeys/s (26103605510632541 keys/s)]

This speed depends not only on the filter but also on monthly code optimization. I updated file in github.

And size filters.
your version (fuse filter -k 64) 751 mb
my version (fuse filter -k 64) 598 mb

https://github.com/Slait/Keyhuntbsgs

[punk_design]

SlaitX

Thanks for the update.

I see you implemented a 16 bit binary fuse filter - false alarm rate = 0.00001

I opted for a 20 bit binary fuse filter - false alarm rate = 0.00000095, (kept it true to the original version).

However, after seeing you speed and performance improvement with a 16 bit binary fuse filter. I modified mine and tested it.
I did get similar performance improvement and memory savings as you did.

With a 16-bit binary fuse filter with false alarm (0.00001)
My file size is ~600 Mb now (20% reduced) and my performance is another 20% improved as well. Now it only needs 2.25 bits per element in the 16 bit table, instead of 2.81 bits per elements in the 20 bit table.

The original false alarm rate might have been too conservative with respect to performance. The risk of performing the binary search is more costly than the filter search, hence the very low false alarm rate.

Next, I'll try a 14 bit table - false alarm rate of 0.00006103. This should make it faster and get another 12% reduction in memory and performance increase. Eventually, the false alarms will negate any performance improvement. Just trying to find the point in which further reductions no longer bring better performance.

[punk_design]

https://github.com/punk-design/keyhunt_binary_fuse_filter/blob/main/BSGS_Binary_Fuse_Analysis.png

Looks like 12 bit might be the best bang for the buck. If I make some further memory optimizations to pack 12 bits into 16 bit or reorder to store into memory more efficient, then it'll perform like 16 bit variant. However, there is an additional 25% memory savings over 16 bit approach. So increasing the search space by 25% with a 6% reduction in processing, puts the processing ahead in terms of performance.

This is 40% memory savings over my original approach of 20 bit. Turns out the defined false alarms can be significantly relaxed, this might be because the hash is uniform and not prone to false alarms.

[JackMazzoni]

according to the table I should use :

256 GB -n 0x400000000000 -k 8192

and rest of my Ram capacity will be in free

Would it be possible to add an option to input either the total memory size or the number of baby steps?

At the moment, a significant portion of memory remains unused, and allowing users to configure this would improve resource utilization and performance.

[SlaitX]

according to the table I should use :

256 GB -n 0x400000000000 -k 8192

and rest of my Ram capacity will be in free

Would it be possible to add an option to input either the total memory size or the number of baby steps?

At the moment, a significant portion of memory remains unused, and allowing users to configure this would improve resource utilization and performance.

To select the appropriate amount of RAM, I recommend choosing -k and -n according to the table at
https://github.com/Slait/Keyhuntbsgs?tab=readme-ov-file#correct-values-for-n-and-maximum-k-for-specific-bits

[JackMazzoni]

according to the table I should use :

256 GB -n 0x400000000000 -k 8192

and rest of my Ram capacity will be in free

Would it be possible to add an option to input either the total memory size or the number of baby steps?

At the moment, a significant portion of memory remains unused, and allowing users to configure this would improve resource utilization and performance.

To select the appropriate amount of RAM, I recommend choosing -k and -n according to the table at
https://github.com/Slait/Keyhuntbsgs?tab=readme-ov-file#correct-values-for-n-and-maximum-k-for-specific-bits

I want to use my full ram capacity.

[SlaitX]

according to the table I should use :

256 GB -n 0x400000000000 -k 8192

and rest of my Ram capacity will be in free

Would it be possible to add an option to input either the total memory size or the number of baby steps?

At the moment, a significant portion of memory remains unused, and allowing users to configure this would improve resource utilization and performance.

To select the appropriate amount of RAM, I recommend choosing -k and -n according to the table at
https://github.com/Slait/Keyhuntbsgs?tab=readme-ov-file#correct-values-for-n-and-maximum-k-for-specific-bits

I want to use my full ram capacity.

Based on the analysis of your computer, I have concluded that you need to create a Bloom filter of 1 TB. For this, I recommend specifying these values:

keyhunt -m bsgs -f test.txt -r 01:999999999999999999999999999999999 -k 90112 -n 0x4000000000000 -x fuse -S -s 10

Important: You must have a swap file of at least 1 TB, preferably 2 TB. You need a minimum of 6 TB of free space (for generate fuse filter) , including the swap file.
For faster generation, I recommend Linux, as filter generation is faster and processor threads work correctly. Windows has a limitation of 64 threads (I have fixed this, but more testing is needed).
The approximate speed should be 1.7 Ekeys/s per thread. If you have 64 threads, the speed will be ~108 Ekeys/s, if you have 192 threads (AMD), then it will be 326 Ekeys/s.

[SlaitX]

I created new version.

1.0.4.20260113
https://github.com/Slait/Keyhuntbsgs

https://raw.githubusercontent.com/Slait/Keyhuntbsgs/main/keyhunt.gif

Corrected the -wif (1 | 0) output for WIF output
Fixed the skipping error
Fixed the filter generation for Windows
Accelerated bloom using 64-bit mix
Accelerated bloom generation
Accelerated AVX2 mathematics
Vectorized Bloom, FUSE, XOR filter checking
Prefetching for XOR Fuse (Filter acceleration)
Huge Pages (Filter acceleration)
Assembler for the double function
Added a blocked filter -x blocked (speed is slow like Bloom, but the size is more compact, not recommended. Currently, FUSE is the best)
FUSE acceleration by 25 CPU cycles

[ibbonmailru]

I created new version.

1.0.4.20260113
https://github.com/Slait/Keyhuntbsgs

https://raw.githubusercontent.com/Slait/Keyhuntbsgs/main/keyhunt.gif

Corrected the -wif (1 | 0) output for WIF output
Fixed the skipping error
Fixed the filter generation for Windows
Accelerated bloom using 64-bit mix
Accelerated bloom generation
Accelerated AVX2 mathematics
Vectorized Bloom, FUSE, XOR filter checking
Prefetching for XOR Fuse (Filter acceleration)
Huge Pages (Filter acceleration)
Assembler for the double function
Added a blocked filter -x blocked (speed is slow like Bloom, but the size is more compact, not recommended. Currently, FUSE is the best)
FUSE acceleration by 25 CPU cycles

Hello
Why such low load of CPU?

https://dropmefiles.com/B5Cdl

on i7-14700K:

https://dropmefiles.com/sgQ3U

[SlaitX]

don't use -R or -B random

[ibbonmailru]

don't use -R or -B random

Ok, its working. But how to run random search? Because range is too big for sequential search.

[ibbonmailru]

Why programm use only 25% of CPU?

https://dropmefiles.com/sgQ3U

params: -f !puz135.txt -m bsgs -S -s 10 -n 0x100000000000 -k 8192 -wif 1 -x fuse -r 4000000000000000000000000000000000:7fffffffffffffffffffffffffffffffff

Threadripper 3990x, 128Gb

[ArtificialLove]

I'm almost sure this is not related but can anyone build (or does anyone know) a tool which can get "key masks" and then use CUDA to check millions of keys per second?
The reason I'm asking is that it appears some keys produce similar hashes just because one character gets repeated again, I might be wrong, but I've reason to believe it's at least to some extent true and I want to try it out but I can't because there is no tool out there that can do that.
e.g.
abcRRRReRRRaRR
Where R is a random character.

Thanks!

[SlaitX]

Why programm use only 25% of CPU?

https://dropmefiles.com/sgQ3U

params: -f !puz135.txt -m bsgs -S -s 10 -n 0x100000000000 -k 8192 -wif 1 -x fuse -r 4000000000000000000000000000000000:7fffffffffffffffffffffffffffffffff

Threadripper 3990x, 128Gb

Windows has an issue with running more than 64 threads. If you need a quick fix, use the Linux version, which doesn't have this issue.

[oddstake]

Based on the analysis of your computer, I have concluded that you need to create a Bloom filter of 1 TB. For this, I recommend specifying these values:

keyhunt -m bsgs -f test.txt -r 01:999999999999999999999999999999999 -k 90112 -n 0x4000000000000 -x fuse -S -s 10

Important: You must have a swap file of at least 1 TB, preferably 2 TB. You need a minimum of 6 TB of free space (for generate fuse filter) , including the swap file.
For faster generation, I recommend Linux, as filter generation is faster and processor threads work correctly. Windows has a limitation of 64 threads (I have fixed this, but more testing is needed).
The approximate speed should be 1.7 Ekeys/s per thread. If you have 64 threads, the speed will be ~108 Ekeys/s, if you have 192 threads (AMD), then it will be 326 Ekeys/s.

Hello sir,
Thanks for your updated version of Keyhunt.
Could you explain a little bit how much HDD space should I have to generate fuse filter for 1T of RAM.
Sorry but it is not clear from "Correct values for n and maximum k for specific bits" table.

[oddstake]

I created new version.

1.0.4.20260113
https://github.com/Slait/Keyhuntbsgs

https://raw.githubusercontent.com/Slait/Keyhuntbsgs/main/keyhunt.gif

Corrected the -wif (1 | 0) output for WIF output
Fixed the skipping error
Fixed the filter generation for Windows
Accelerated bloom using 64-bit mix
Accelerated bloom generation
Accelerated AVX2 mathematics
Vectorized Bloom, FUSE, XOR filter checking
Prefetching for XOR Fuse (Filter acceleration)
Huge Pages (Filter acceleration)
Assembler for the double function
Added a blocked filter -x blocked (speed is slow like Bloom, but the size is more compact, not recommended. Currently, FUSE is the best)
FUSE acceleration by 25 CPU cycles

I tried your version.
Indeed, it's faster than Alberto’s version - about 2× faster with your bloom tables. I also tried using fuse tables, but I don’t have enough SSD resources.
However, it’s still not worth it. It solves puzzle 80 in about 28 minutes and 14 seconds (including the time needed to fill the tables into memory) at an average speed of ~354 Ekeys/s.

Code:

./keyhunt -m bsgs -f 80.txt -r 80000000000000000000:ffffffffffffffffffff -n 0x1000000000000 -k 16384 -t 192 -q -S -s 1
[+] Version 1.0.4.20260113 Slait Edition, developed by AlbertoBSD
[+] K factor 16384
[+] Threads : 192
[+] Quiet thread output
[+] Stats output every 1 seconds
[+] Mode BSGS sequential
[+] Opening file 80.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x80000000000000000000
[+] -- to   : 0xffffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points



[+] Thread 0xea0f593a000000000000 | [500853889413563373584384 keys][1414 sec][~354 Ekeys/s (354210671438163630540 keys/s)]
[+] Thread Key found privkey ea1a5c66dcc11b5ad180
[+] Publickey 037e1238f7b1ce757df94faa9a2eb261bf0aeb9f84dbf81212104e78931c2a19dc
All points were found
28m 14s

I also tried random mode (-R) on puzzle 80, but it’s even harder — I couldn’t find anything after letting it run for more than an hour.
RCkangaroo solves the same puzzle 80 in less than 1 minute on an RTX 4080.
So the difference is clear. It’s not worth it, even on my high-end specs:

AMD EPYC 9965 (192 cores / 384 threads)
1 TB DDR5 6400 MT/s
2TB Samsung 990 PRO

So, anyone thinking about investing in expensive hardware components should think twice.

Here is the proof with puzzle 75, only a few seconds for this low bits puzzle. The speed is good but currently it's not worth it on CPU, just my thought.
https://ibb.co/B2NnMbJw

Happy hunting !

[SlaitX]

So, anyone thinking about investing in expensive hardware components should think twice.

Here is the proof with puzzle 75, only a few seconds for this low bits puzzle. The speed is good but currently it's not worth it on CPU, just my thought.
https://i.ibb.co/RTyjwfK7/Recording-2026-02-13-165014.gif

Happy hunting !

Thanks for the test. I only optimized the sequential mode. I didn't touch the random mode, as I needed the sequential mode.

[oddstake]

Here's a better version of puzzle 75 proof.

https://ibb.co/B2NnMbJw

Time reading the filter : 4m 28 sec which is very nice.
Alberto's original Keyhunt took me about an hour to fill 1T of RAM.

Also, I tried every linux distribution out there, spent lot of time installing and reinstalling.
The best distro for Keyhunt is CachyOS. The speed is way higher than Ubuntu or Debian.
Everyone should try it.

Code:

           .-------------------------:                    cachyos@cachyos-gigabyte
          .+=========================.                    ------------------------
         :++===++==================-       :++-           OS: CachyOS x86_64
        :*++====+++++=============-        .==:           Host: MZ33-CP1-000 (5MZ33CP1MR-000)
       -*+++=====+***++==========:                        Kernel: Linux 6.18.9-3-cachyos
      =*++++========------------:                         Uptime: 5 hours, 46 mins
     =*+++++=====-                     ...                Packages: 853 (pacman)
   .+*+++++=-===:                    .=+++=:              Shell: fish 4.4.0
  :++++=====-==:                     -*****+              Display (DP-1): 1024x768, 60 Hz [External]
 :++========-=.                      .=+**+.              Terminal: /dev/pts/0
.+==========-.                          .                 CPU: AMD EPYC 9965 192-Core (384) @ 3.70 GHz
 :+++++++====-                                .--==-.     GPU: ASPEED Technology, Inc. ASPEED Graphics Family
  :++==========.                             :+++++++:    Memory: 17.02 GiB / 1.11 TiB (2%)
   .-===========.                            =*****+*+    Swap: 12.00 KiB / 1.98 TiB (0%)
    .-===========:                           .+*****+:    Disk (/): 7.52 GiB / 37.61 GiB (20%) - ext4
      -=======++++:::::::::::::::::::::::::-:  .---:      Disk (/home): 953.83 GiB / 1.79 TiB (52%) - ext4
       :======++++====+++******************=.             Local IP (enp166s0): 192.168.0.140/24
        :=====+++==========++++++++++++++*-               Locale: en_US.UTF-8
         .====++==============++++++++++*-
          .===+==================+++++++:
           .-=======================+++:
             ..........................

[arulbero]

Here's a better version of puzzle 75 proof.



Time reading the filter : 4m 28 sec which is very nice.
Alberto's original Keyhunt took me about an hour to fill 1T of RAM.

Just to clarify, is the filter precomputed?

How much time it takes to find a #75 key ? Only few seconds?

[oddstake]

Just to clarify, is the filter precomputed?

Yes, precomputed bloom filter, same as original keyhunt but Slait version has a few enhancements.

How much time it takes to find a #75 key ? Only few seconds?

Yes, only a few seconds as you can see in the .gif

Here is scanning some ranges, about 200 seconds for each subrange of 76 bits.

Code:

❯ ./keyhunt -m bsgs -f 135.txt -D deep.txt -n 0x1000000000000 -k 16384 -t 192 -q -s 1 -S
[+] Version 1.0.4.20260113 Slait Edition, developed by AlbertoBSD
[+] K factor 16384
[+] Threads : 192
[+] Quiet thread output
[+] Stats output every 1 seconds
[+] Mode BSGS sequential
[+] Loaded 13 ranges from deep.txt
[+] Opening file 135.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x5851eb8551eb8550000000000000000000
[+] -- to   : 0x5851eb8551eb855fffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points
[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_1_274877906944.blm (headers) Done!
[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_2_8589934592.blm (headers) Done!
[+] Reading bP Table from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_4_268435456.tbl .[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_3_268435456.blm (headers) Done!
[+] Time reading the filter: 4 min 42 sec


[+] Range 1/13
[+] -- from:0x5851eb8551eb8550000000000000000000
[+] -- to  :0x5851eb8551eb855fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 2/13
[+] -- from:0x5851eb8551eb8560000000000000000000
[+] -- to  :0x5851eb8551eb856fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 3/13
[+] -- from:0x5851eb8551eb8570000000000000000000
[+] -- to  :0x5851eb8551eb857fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 4/13
[+] -- from:0x5851eb8551eb8580000000000000000000
[+] -- to  :0x5851eb8551eb858fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s

It will take billions of  years to search like this and find the puzzle 135 key.