this is pubkey divided to 1024, show ranges pkease ?
029f29301b11ba20f351982949eaa5a65c30dcb7e0bd7ea64a86ce74b11ad2f6ca
?
I realy not understand what ranges you will show, because all 5 /3, 9 /2, 232 / 44 ... contain int part, and this part is unknown.
thanks ! The traditional way of dividing a pubkey by 1024, you will have 1024 new pubkeys, and you have shrunk the range by 2^10. But each pubkey will be in a different range. I know all the ranges where the pubkeys will be, but I do not know which pubkey will be in each range. So if you shrunk the range by 2^10, the new range will look like this 2000000000000000000000000000:3FFFFFFFFFFFFFFFFFFFFFFFFFFF or like this 0000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFF |
|
|
|
|
What does this means, Divide by 0! ?
|
|
|
|
This is an example from the data.json file from https://github.com/bitlogik/lattice-attack{"curve": "SECP256K1", "public_key": [66412380102939781024918160349386680014552536369061587637080774389860461092925, 43765600116551195273677149966008783624760986110490190619082891899095205821463], "known_type": "LSB", "known_bits": 6, "signatures": [{"r": 77527664235581399957092079345479688400475999610428178825522649055070157244692, "s": 27028479468528243957334746793835087615740874028178347534667218420099431266524, "kp": 51, "hash": 36925504434266069211917383521197840104244330385311344434522880060028429358956}, {"r": 1695214956238129249280118258814363243967244974939577175204794511553033886344, "s": 84915535421556974430475608108845062567200591001138706902138971666887762297461, "kp": 23, "hash": 76485972818364982894032873079629726025969313708578174583231327504986349400949}, {"r": 109269381046386034156037076068908319933850763940108273610325408412215759654951, "s": 48609197671516297208867726715248596584655415925682996149314879813291177259719, "kp": 49, "hash": 8857850795789766547675189849758610890848461200122419912004299328172940180927}, {"r": 41835540276419198058500360048414380626372941221767888918686846392248041576696, "s": 1825469084617584873286736453038639812754935222429578990673573348028125348352, "kp": 29, "hash": 11771613120662486178657899205469606751879506909643902145426207541353014498651}, {"r": 107103142771724135475440435595118756234545765813796109423691918131480012001322, "s": 76403726951992633295737606623610572293691262686449016257400538234410247449075, "kp": 44, "hash": 109029154205057617106956764551702586575882058359417649302233515615948131520073}, {"r": 54544573696288124190943111180088654937224138523771919858599448193516058012815, "s": 75774534848938869077595821409914703967303095416625781047518021857023231109081, "kp": 44, "hash": Is this the public key its trying to look for [66412380102939781024918160349386680014552536369061587637080774389860461092925, 43765600116551195273677149966008783624760986110490190619082891899095205821463] ? So I convert the r,s,z into decimal, I see the r and s. Which one is the z, is it the kp? I'm trying to see what goes where. |
|
|
|
They both work, it just depends on what key you are looking for. |
|
|
|
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. |
|
|
|
I already told you to just change lines 17 and 18 to 256 and it will work https://asecuritysite.com/ecc/ecdk1 = random.randrange(1, pow(2, 256)) k2 = random.randrange(1, pow(2, 256)) private key ot found. only message"private kwy", but no second message "privatevkey found" What private key it was looking for because it was random |
|
|
|
I already told you to just change lines 17 and 18 to 256 and it will work https://asecuritysite.com/ecc/ecdk1 = random.randrange(1, pow(2, 256)) k2 = random.randrange(1, pow(2, 256)) |
|
|
|
|
I was attempting to use this but did get a lot if errors.
|
|
|
|
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. 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. |
|
|
|
Just change lines 17 and 18 to 256 k1 = random.randrange(1, pow(2, 256)) k2 = random.randrange(1, pow(2, 256)) |
|
|
|
|
What algorithm or tool so far that can do 2^160 or 2^96 search range. Only thing I can think is vanitygen and vanity search.
|
|
|
|
Use whatever you want, just not from that russian thief. All he does is copy/paste from other repos (not fork), he changes name and says like it belongs to him. I also cannot recommend his tools, especially when he ran shady brute-force challenge[1]. But i'm not sure he can be called thief when AFAIK he don't violate original repository license. Although i can understand uneasiness that he don't use GitHub fork feature when the original source code also hosted on GitHub. [1] https://bitcointalk.org/index.php?topic=5394745.0If his tools work, they work. If the challenge is fake or if you think its fake just don't participate in it. |
|
|
|
@fxsniper
Hello
You won't notice much speed difference on this case.
Only thing pubkey bruteforce fastest is BSGS, because it's come after only 1 step(value*G). no need double SHA2,RIPEMD160,BASE8
address or RIPEMD160 won't make much noticeable difference in bruteforce.
OK, I just think simple maybe calculate SHA-256 and RIPEMD160 it is maybe fast that Elliptic curve point calculate I think with 1 step(value*G). it is calculated 256 times (loop) for each bit maybe make full key brute-force slow You can use this too for Hash160 https://github.com/phrutis/Rotor-Cuda you can use a GPU with this. |
|
|
|
Brainless hack this adresses ? Are you sure it was Brainless, if so, I wonder how he did it? |
|
|
|
[+] 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 4096
[+] Quiet thread output
[+] Threads : 50
[E] Unknow opcion -p
[+] Mode BSGS random
[+] Opening file 4000.txt
[+] Added 1 points from file
[+] Bit Range 256
[+] -- from : 0x8000000000000000000000000000000000000000000000000000000000000000
[+] -- to : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
[+] N = 0x100000000000
[+] Bloom filter for 17179869184 elements : 58890.60 MB
[+] Bloom filter for 536870912 elements : 1840.33 MB
[+] Bloom filter for 16777216 elements : 57.51 MB
[+] Allocating 256.00 MB for 16777216 bP Points
[+] processing 17179869184/17179869184 bP points : 100%
[+] Making checkums .. ... done
[+] Sorting 16777216 elements... Done!
[+] Total 21063423857946682982400 keys in 18450 seconds: ~1 ExaKeys/s (1141648989590606123 keys/s)
In random mode, how often does the range change ? Can we set the parameter somehow ? Every second it hashes its random |
|
|
|
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 |
|
|
|
|
albert0bsd, would it be better to use a .bin than a .blm to store the public keys?
That shouldn't effect the overall speed.
|
|
|
|
|
Its 80 bits in the 120 bit range, not 80 bits in the 80 bit range. Its not like that at all, its a 80 bit difference on the 120 key.
|
|
|
|
I found a method to find any private key within 2^255 bit space. Is that new?
Depends on what the method is, what is the method? |
|
|
|
|
Show Posts
