Keyhunt - development requests - bug reports

[bigvito19]

Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode.

I don't quite understand what you are trying to convey. We're already looking for a ^120-bit range, how come in BSGS mode you detect a ^120-bit field as ^60-bits?

Also, loading 2 billion 700 million points in BSGS mode will not be efficient. Searching for a point with the -R option will take much longer.

Using xpoint mode is the slowest way to find a collision, 2^120/2^31 so of course you're not going to find anything. Use BSGS mode instead 2^60/2^31. You have to search the whole range in xpoint mode vs BSGS mode.

[1715322325]

1715322325

[1715322325]

1715322325

[1715322325]

1715322325

[1715322325]

1715322325

[1715322325]

1715322325

[nomadsena]

hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods  that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.

[WanderingPhilospher]

hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods  that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.

Interesting question, but to me, it's not as easy as one or the other. It's not black and white.

With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach.

[nomadsena]

hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods  that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.

Interesting question, but to me, it's not as easy as one or the other. It's not black and white.

With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach.

Hi thanks for replying, I am aware of the fact that collisions exist and its not as simple as that first 2^160 private keys align with the RIPEMD 160 range. and sorry to correct 50% key range is 0-2^255 and remaining 50% 2^256 that's how exponential numbers work. My question was, tools like bitcrak has to search in the range of 2^160 private key space to find a collision, meaning it maynot be the same private key but can be hashed to get the same wallet address but BSGS has to search in the range of 2^256 as it calclates K from publickey. so this means it is better only for solving the puzzle and not any random wallet for which the public key is known?...
And albert0bsd your inputs are needed here.    

[WanderingPhilospher]

hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods  that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.

Interesting question, but to me, it's not as easy as one or the other. It's not black and white.

With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach.

Hi thanks for replying, I am aware of the fact that collisions exist and its not as simple as that first 2^160 private keys align with the RIPEMD 160 range. and sorry to correct 50% key range is 0-2^255 and remaining 50% 2^256 that's how exponential numbers work. My question was, tools like bitcrak has to search in the range of 2^160 private key space to find a collision, meaning it maynot be the same private key but can be hashed to get the same wallet address but BSGS has to search in the range of 2^256 as it calclates K from publickey. so this means it is better only for solving the puzzle and not any random wallet for which the public key is known?...
And albert0bsd your inputs are needed here.  

Where did I mention 50% of 2^256?  I stated that with Kangaroo you would have to complete roughly 2^129 group operations (with a DP of 0), 256 / 2 + 1 = 129. If you used a DP of 30, 256 / 2 + 1 = 129; 129 -30 = 99, so you would have to complete roughly 2^99 group ops. Far less than 2^160.  Do you understand how Kangaroo and BSGS work?

But you can find any and all keys in a 2^255 keyspace. So realistically, 128.5 group ops at DP 0, 2^98.5 group ops at DP 30, 2^88.5 group ops at DP 40...as you can see, it is exponentially faster searching for a pubkey versus possibly searching a 2^160 space for a possible collision.

[asicprince]

sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks

[NotATether]

sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks

MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS.

Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support).

It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS.

[PawGo]

MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS.

Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support).

It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS.

I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer).
The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong.

Use Java ;^)

[WanderingPhilospher]

MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS.

Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support).

It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS.

I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer).
The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong.

Use Java ;^)

He said "powerful code"...which Java is not for what they want to do ;^)

[PrivatePerson]

sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks

1. You can use Parallels Desktop to install linux os.
2. Try https://brew.sh/

[NotATether]

I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer).
The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong.

Use Java ;^)

I don't think there are any packages for talking to GPUs [At least there weren't the last time I read the big Java reference book], so it would only be good for multi-threaded CPU stuff.

Then again, maybe there is an OpenCL package somewhere for this, but how would such a thing be implemented in a cross-platform way?

[PawGo]

I don't think there are any packages for talking to GPUs [At least there weren't the last time I read the big Java reference book], so it would only be good for multi-threaded CPU stuff.

There is jcuda http://javagl.de/jcuda.org/
I have seen some videos and examples, it looks promising, but I did not use it yet, as I decided to go to fully c project.

Apple provide Rosetta which could run x86_64 application[1]. Some benchmark on Apple M1 report it has decent performance[2], so why bother re-write Keyhunt code on java? IMO it's more practical to find way to compile Keyhunt on Mac environment instead.

It was not my intention, it was just a general remark about the solution which works on any platform.
Using pure java it is very difficult to have a performance comparable with a good c program. Let's forget about any ideas for rewriting keyhunt!

[Spawnx]

I tested via Windows 10 and all modes work.

Code and exe files are on github.

Thank you so much

Hey WanderingPhilospher , how do You run Your version on win 10? , using standard command promp in Win gives missing libraries errors, complete Linux noob here btw 

Try this one instead doesn't give errors https://github.com/XopMC/keyhunt-win

Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC

[albert0bsd]

Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC

If you have Linux compile it by yourself and post here the error if  it persist.

[Spawnx]

Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC

If you have Linux compile it by yourself and post here the error if  it persist.

Hey albert0bsd, below is the error, im using the compiled Windows version

Code:

C:\Users\Administrator\Desktop\keyhunt-win-KeyHunt0.2.211222ServerEdition\keyhunt-win-KeyHunt0.2.211222ServerEdition>keyhunt.exe -m bsgs -f 120.txt -b 120 -R -n 0x400000000000 -k 8192 -q -t 38
[+] Version 0.2.211222 SSE Server Edition ,modify Dusky Kam 3,compiled by @XopMC for t.me/brythbit, developed by AlbertoBSD, developed by AlbertoBSD
[+] Random mode
[+] K factor 8192
[+] Quiet thread output
[+] Threads : 38
[+] Mode BSGS random
[+] Opening file 120.txt
[+] Added 1 points from file
[+] Bit Range 120
[+] -- from : 0x800000000000000000000000000000
[+] -- to   : 0x1000000000000000000000000000000
[+] N = 0x400000000000
[+] Bloom filter for 68719476736 elements       1 [main] keyhunt 130 cygwin_exception::open_stackdumpfile: Dumping stack trace to keyhunt.exe.stackdump

C:\Users\Administrator\Desktop\keyhunt-win-KeyHunt0.2.211222ServerEdition\keyhunt-win-KeyHunt0.2.211222ServerEdition>

[albert0bsd]

I don't support to windows version, sorry, please use Linux

[PawGo]

Hey albert0bsd, below is the error, im using the compiled Windows version

Using cygwin?
If you do not have access to "pure" linux, I think it is better to try WSL - https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux - for me it works flawlessly. And it is your choice to install debian or ubuntu. which version etc.

[psychoid]

My apologies for such a dumb question, but could someone explain is there a benefit to running "-k" K factor of 4096 vs 2048? because in the end the matrix size is 16x16=256 bits or I'm just too dumb to understand it. and how big is the difference?

[albert0bsd]

Yes the WSL is the best option to work with keyhunt in windows, that is what I use in my laptop.

My apologies for such a dumb question, but could someone explain is there a benefit to running "-k" K factor of 4096 vs 2048? because in the end the matrix size is 16x16=256 bits or I'm just too dumb to understand it. and how big is the difference?

Matrix size??? I think that you are mixing concept from others programs, there are no matrix size on keyhunt.

Doubling the size of the K factor also double the speed and the memory usage.

Regards

[DeepComplex]

Albert0bsd,

Any updates for keyhunt?

Regards,