Pages:
Author

Topic: Keyhunt - development requests - bug reports - page 19. (Read 15202 times)

member
Activity: 174
Merit: 12
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/
full member
Activity: 1232
Merit: 242
Shooters Shoot...
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 ;^)
legendary
Activity: 952
Merit: 1386
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 ;^)
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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.
newbie
Activity: 8
Merit: 1
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
full member
Activity: 1232
Merit: 242
Shooters Shoot...
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. Smiley  
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.
member
Activity: 93
Merit: 10
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. Smiley   
full member
Activity: 1232
Merit: 242
Shooters Shoot...
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.
member
Activity: 93
Merit: 10
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.
full member
Activity: 706
Merit: 111
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.
newbie
Activity: 16
Merit: 1
Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?!
Also, how long did it take for the program to load all of those xpoints before it started working?

I don't remember exactly, but on average:

It took 5-6 hours to generate the file with keysubtructer.

Code:
-rw-r--r-- 1 root root 180900000067 May 12 23:20 200.txt

Booting with keyhunt took about 3 hours.

Code:
/0/4                      processor      Intel(R) Xeon(R) Platinum 8370C CPU @ 2
/0/6                      memory         64GiB System Memory
full member
Activity: 1232
Merit: 242
Shooters Shoot...
I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man.

Code:
root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Threads : 8
[+] Mode xpoint
[+] Random mode
[+] Quiet thread output
[+] Stride : 1267650600228229401496703205376
[+] Opening file 200.txt
[+] N = 0x80000
[+] Range
[+] -- from : 0x800000000000000000000000000000
[+] -- to   : 0x80000fffffffffffffffffffffffff
[+] Allocating memory for 2700000001 elements: 51498.41 MB
[+] Bloom filter for 2700000001 elements.
[+] Loading data to the bloomfilter total: 9255.29 MB
[+] Bloomfilter completed
[+] Sorting data ... done! 2700000001 values were loaded and sorted
[+] Total 2626285058048 keys in 155310 seconds: ~16 Mkeys/s (16909954 keys/s)
Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?!
Also, how long did it take for the program to load all of those xpoints before it started working?
member
Activity: 406
Merit: 47
Thank you albert0bsd
I will try to read and make understand

Did BSGS have code in python so I can read the code and run a test it to make understand?
newbie
Activity: 16
Merit: 1
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.
full member
Activity: 706
Merit: 111
I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man.

Code:
root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Threads : 8
[+] Mode xpoint
[+] Random mode
[+] Quiet thread output
[+] Stride : 1267650600228229401496703205376
[+] Opening file 200.txt
[+] N = 0x80000
[+] Range
[+] -- from : 0x800000000000000000000000000000
[+] -- to   : 0x80000fffffffffffffffffffffffff
[+] Allocating memory for 2700000001 elements: 51498.41 MB
[+] Bloom filter for 2700000001 elements.
[+] Loading data to the bloomfilter total: 9255.29 MB
[+] Bloomfilter completed
[+] Sorting data ... done! 2700000001 values were loaded and sorted
[+] Total 2626285058048 keys in 155310 seconds: ~16 Mkeys/s (16909954 keys/s)

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.
newbie
Activity: 16
Merit: 1
I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man.

Code:
root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Threads : 8
[+] Mode xpoint
[+] Random mode
[+] Quiet thread output
[+] Stride : 1267650600228229401496703205376
[+] Opening file 200.txt
[+] N = 0x80000
[+] Range
[+] -- from : 0x800000000000000000000000000000
[+] -- to   : 0x80000fffffffffffffffffffffffff
[+] Allocating memory for 2700000001 elements: 51498.41 MB
[+] Bloom filter for 2700000001 elements.
[+] Loading data to the bloomfilter total: 9255.29 MB
[+] Bloomfilter completed
[+] Sorting data ... done! 2700000001 values were loaded and sorted
[+] Total 2626285058048 keys in 155310 seconds: ~16 Mkeys/s (16909954 keys/s)
hero member
Activity: 862
Merit: 662
Imagine that you have one Single operation to check if some Publickey P(x) is between some fixed range lets to say from 1 to 1M such operation will be like:

Code:
if 1 <= P(x) <= 1M
print "Found :)"
else
print "Not Found :("

That operation doesn't exist because Public keys are hidden numbers they hide the x value (Private key)

So, what happened if you have the Cache of the first million keys, you only need to have a function that let you know if some publickey is inside of one array

Code:
if is_publickey_in_array(P(x),array)
print "Found :)"
else
print "Not Found :("

to be computationally efficient, that function need to be fast O(1), There are a lot of Data structures that can do that, Hashtables, maps, bloomfilters etc, or some combinations between them.

What BSGS Do?

The first step is try to translate the P(x) to the keyspace between 1 to 1M (This amount can be changed this depends of the available memory), this operation is done by one single subtraction.

Lets to say that the value of x is 100123987

Code:
P(100123987) = 03992723319651c25a1e3dc624af41a8625a90c3c455f806a4a2b385175750b211
P(100000000) = 03df77e24113f1c6093dc99e62e63737c97821c854bf03b171b7fefbd81acec408
P(100123987) - P(100000000) = P(123987)
P(123987) = 02ee35e4236c7b0b269c88b1da75b9a068a7227bd847a931c55587ec4017b2cd98

If we check for the function that value of P(123987) is in the array is_publickey_in_array(P(x),array) then the the result will be that we found the key, you only need to find what of those Million of values is your key and then just do some additions to recover the original KEY.

For the previous example imagine that you start from 1 to reach 100M you only need 100 Point Subtractions and 100 checks in the arrays, so instead of bruteforce that publickey 100 Million times you only need 100 basic operations that is why bsgs is some fast

This is a basic example, the real BSGS need some extra considerations like work with Perfect squares numbers, and also will be better if we work with Base 2 numbers like  2^Y numbers

This is an example with One million of publickeys in cache, now imagine what you can do with with some Billions of keys in your cache.

you can read more of BSGS in https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/


I assume that in BSGS mode there no no such option as random changed key after a given key value searched?

The -R option enable the random search, every time that one thread do a search it chose a different random number, this is EVERY single cycle one random number is chossen.

Regards!
member
Activity: 406
Merit: 47
Please guys stay on keyhunt topic, avoid any comment of those fake wifs

Hi, albert0bsd

I would like to understand BSGS, Can you help to explain some methods? (I can study in detail more)
I understand kangaroos (a little some part) and understand some entropy or scalar for the Elliptic curve convert private key to public key
a lot of bitcoin and cryptography I do not yet understand clear
newbie
Activity: 48
Merit: 0
Hey albert0bsd,

I assume that in BSGS mode there no no such option as random changed key after a given key value searched?

Something like in VanitySearch there is -r as for random but also a value after how many searched keys the key is changed

hero member
Activity: 862
Merit: 662
Please guys stay on keyhunt topic, avoid any comment of those fake wifs
Pages:
Jump to: