Title: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: digaran on March 14, 2023, 12:14:56 PM I would like to discuss about implications of collisions if found.
Dangers to the whole system. Known methods of exploit. Countermeasures. What are the possible contingency plans? Do's and don'ts in case of discovery. What should be the community's reaction? How could we prepare the entire market, miners, nodes, services, traders, long and short investors and end users? In case if you are unaware, we are in uncharted territory where nobody is going to rush in to help us if a disaster occurs, decentralized economy means that we need to have a plan A, B, C and even more, it's not just about a few keys and coins being exposed, it is rather much bigger than that, one thing I could think of was the fact that if a collision especially in SHA-256 is to be found, discarding the importance of what might happen to governments and their infrastructures considering they're dependent on the security of such algos, we can't simply ignore hundreds of billions invested in crypto markets, hence the need to come up with ideas to mitigate the damage and minimize the losses as much as possible. I might in the future devise an article to publish on the net, hopefully we could spread the words so that everyone know that we have plans in place for every unforeseen unfortunate event that might come our way. It's called crisis management. I love it here, this is my luxurious penthouse at the loneliest place in the world, welcome.😉 Title: Re: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: digaran on March 19, 2023, 04:23:51 AM Reposting here because I don't want to clog other threads.
I hope this act as a heads up for manufacturers, miners, developers, this also could be a known fact, I haven't seen it discussed any where. Demonstrating two collision attacks in details. This is a unc public key: [1]0425f587ba19c90b6e4a6606929bc6a01c44a051805797662ca2cb735dba3c009859f01d2a9e6fa d26fd0fda518271ab0dc32e9a9de6ad3b0f000bd09edfa98ca3 We perform RMD160 on it: [3]dacb99a98b80d48adbd8b94c9a7905996503d2ab Result: [2]1LwtDDHxpvo6Uh9sbRTNSU7r5rukqCFRGC Now, since there are no SHA-256 hash that long[1] if we find the actual public key of our address[2] and perform a SHA-256 on it, the resulting hash which is a 64 char long hex will produce the same RMD160[3], therefore the SHA-256 of [2]'s actual public key and our fake hash[1] of a public key collide with each other on RMD160 hash function, 2 different inputs with one unchanged output. Second attempt, this time on SHA-256. We take this and use it as our public key: [6]dacb99a98b80d48adbd8b94c9a7905996503d2ab Then we perform a SHA-256 on it to get our hash of pub ready to convert to an address: [5]32f51406f6d584a5b62365de425d01f308fc56a33682492284cc7577ceeb8868 Now we do a RMD160 on it: 6c161fcca8bbd0fe7a393b11b0499bb0754e3f7f And the resulting address is: [4]1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq Once again we have arrived at the scene of a collision, if you find the actual public key of [4], and perform a SHA-256 on it, you will see that the result is the same as[5], which means [6] and the actual public key of [4] which are different in value and length etc, collide with a similar SHA-256 hash, 2 different inputs, producing 1 unchanged output. Do that long enough on too many objects, you will have a collection of collisions, conditionally if you could find the public keys of your generated addresses though. More over, there are some funded addresses and obviously their owners are unaware that they are holding the key to an actual collision, sooner or later people will figure this out and will exploit it, also the owners of such addresses should transfer their funds to avoid unwanted stalkers, I imagine that top level gov agencies already are aware of this, the reason for publishing this, is to prevent unexpected harm to people and to the entire crypto-system in the future. I'm also studying and experimenting on elliptic curve, and since I was always sleeping in math classes, I'm a bit slow and the progress is disappointing. What I don't understand about EC is the possibility of 2 different private keys having identical public keys, if that really is a fact then who ever designed it, didn't know what he was doing or it was done on purpose, because applying the same mathematical equations on different input values should never result in an identical(collision) outputs, maybe I don't get the underlying mechanism of EC. Moving on, as explained in the quoted post above, now we know that the possibility of hash collisions is much higher than with collisions of private keys/ public keys, hence the notion of 2^96 identical keys for each address, but I think there is something wrong with that, addresses are not the product of math equations, they are produced by hashing the public key twice, taking the obvious fact of those two hashes colliding chaotically with any random data in to account, we arrive at the conclusion that there exist different public keys which produce the same hash(collision), that is why we speculate about the numbers of 2^96 colliding private keys. I just proved(in practice with examples) that we could have several identical addresses but with different corresponding public and private keys, they might look the same but in reality they are different. I don't know if there has been any case of 2 identical addresses/hashes inside the blockchain with 2 different valid signatures? Since I'm noob about transactions, is the hash 160 or hash 256 of public key involved in the process of validating signatures/ scripts or not? If they are involved then here we just found a security breach in bitcoin(cryptography). But if signatures/ scripts are signed by private keys and public keys are not involved, we are fine. Let me go and check..... Ok it looks like you use prv key to sign and the hash of the next owner's public key, quick question though, how do you prove your ownership of an address if there are several identical public key hashes corresponding with the same address? By using your prv key to sign! But again if a hash is performed on the public key to derive the correct address to check the validity of signatures, then other actors with the same hash could manipulate the data in the signature, is that why so many people are interested in r,s,z,k etc, they want to perform such attacks? Well that could mean they already have colliding keys and now are trying to trick the protocol to steal coins from others. This indicates that we need to persuade people to use an address only once and never store funds on reused/ exposed addresses. Note to Satoshi, chop chop my man, your treasure is in danger.😉 Disclaimer: I do not claim to be an expert, what I say is my own understandings of things, they might be inaccurate/ wrong, and others could point out my mistakes, so don't take my words for it. Title: Re: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: digaran on March 22, 2023, 05:46:37 PM After some thinking, I have decided to publicly disclose any possible method/scenario which we could easily find hash collisions, however the 2 hash functions used in bitcoin act as firewalls to keep the public keys out of sight, though SHA-256 has more importance than RMD-160, As RMD-160 is used to reduce data storage costs, SHA-256 is used in mining operation and is also a critical component in web security and data integrity.
I would like to discuss about the possibilty of utilizing a custom made elliptic curve with a secret back door where it makes it possible for the designer to obtain any of the desired values from the curve, i.e. finding the private key of any given public key on demand. In this scenario I would like to point to the obvious, according to the post above, we could use it as an algorithm to efficiently find collisions, albeit this efficiency is not taking secp256k1 in to account, but if we had a back doored elliptic curve, we could use the same method to collect as many collisions as we want. Here is how it would work, imagine we hash a random string such as "09cfeaabc56772544daee0b346" to get a 256 hash, and then converting that hash to an address just to use our back door and derive the private key for that address to see it's public key, since our made up EC has no public key like the random string above, we now know for sure that the hash 256 of our random string and our now accessible public key are colliding in SHA-256 algorithm. Further more, since we have 2^96 spare/colliding private keys on secp256k1, we could devise an algorithm to generate a key collision on our back doored EC and use it on secp256k1 to control an address. This one requires advanced mathematical science and is extremely difficult, but the hash collision scenario does not require the same. Disclaimer: I'm not an expert in cryptography, mathematics etc, you should consult a professional before reacting to anything I post. Title: Re: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: franky1 on October 06, 2023, 04:08:29 AM if concerned then use a 2-of-2 multisig requiring 2 keys to sign the utxo funds movement.
the odds of someone colliding 1 key is mathematically difficult but to find a pair of 2 randomly chosen keys that work together for a multisig are difficult2 (difficult*difficult) if you are extremely concerned try 3-of-3 multisig.. difficulty3 (difficulty*difficulty)*difficulty if you are exceedingly extremely concerned try 4-of-4 multisig.. difficulty4 ((difficulty*difficulty)*difficulty)*difficulty if you are excessively exceedingly extremely concerned try 5-of-5 multisig.. difficulty5 (((difficulty*difficulty)*difficulty)*difficulty)*difficulty Title: Re: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: digaran on October 06, 2023, 05:11:09 PM Oh hi, welcome to my humble penthouse, thanks for your advices, but I am not concerned about my keys, as I was working on hash functions and collisions I got distracted from this topic by a more promising topic aka DLP solving challenge, I may never revisit my studies on hashes etc.
I believe the danger of solving the DLP is much greater than finding hash or ecc key collisions. So I had to choose what seemed to be the most impossible task, otherwise where would be the fun if not going after such difficult challenges, ehh. 😉 Title: Re: Dangers, exploit methods and countermeasures regarding Collisions!!! Post by: digaran on January 01, 2024, 05:58:09 PM I had this for a long time wanting to share but had other things to do, here is the method on how to find sha256 hashes with any leading hexadecimal characters. And this is based on elliptic curve alone, I haven't tried randomly hashing strings like how Bitcoin miners doing it.
Here are some examples, perform double sha256 on the following: Code: 80e706dc2427605e0a93d8e40320f73acc25607879af54b68db757111111111111 Here is the method : "We make a fake WIF in any desired range, even out of EC range, we give it a fake checksum, then we use wifsolver cuda with a stride of for example 100000000 and we give it our desired checksum, for example 00000000 then it will start grinding to find us a wif with our set checksum, though we would need to leave target blank, we could use either -c or -u for compressed/uncompressed, optional. we will then decode the found wif and remove the last 8 characters and then perform a base 58 checksum encode, the resulting wif will have a checksum like 00000000 or anything we have already set." |