Author

Topic: Dangers, exploit methods and countermeasures regarding Collisions!!! (Read 398 times)

copper member
Activity: 1330
Merit: 899
🖤😏
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
80e706dc2427605e0a93d8e40320f73acc22eb705a4f54b68db757111111111111
80e706dc2427605e0a93d8e40320f73acc210dc5440f54b68db757111111111111
80e706dc2427605e0a93d8e40320f73acc1e4f5a5f9a10fafab757ee59e3a22222
80e706dc2427605e0a93d8e40320f73acc1e4f5a5f8daa6becb757ee59e3a22222
80e706dc2427605e0a93d8e40320f73acc1e4f5a5f7126682ab757ee59e3a22222
80f99ffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e9013e4c4cb
80f99ffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8f9ff2d92b
80f99ffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8f9bfed9af
80f70abfde541181111111111111111111111efefbcdab1776093dea5ecbe00a96
801111111111111111111111111111111111111111111111111111111a63d63ec2
8011111111111111111111111111111111111111111111111111111119c280833e
8099999999012640c71c019cb8af93fb8df67fc2d0d7de99999999999df130e5f9
8099999999012640c71c019cb8af93fb8df67fc2d0d7de99999999999a8ca0958b
80000002cf6509956ce097e4b48a54e07549c1c68f8c09d5a9b3dec02cb9192b81
80000002c22d4cc0562e53997b34ad9a3b70808427cdbd2df22cb72f3da0a93001
80000000ce5640cfb8168777b4d0c98c6261e6a57feaf08b04b4a92212b7b3f901
80000000c50d9434f94de9512e5ed8823e468d4e7515f5f902baafb97be77dc981
800000007994c5273b58b6633ae9bfc284126def488b15c1ec94654f434d312281
80000000940f342d242959cce99917aa5778b99485079889ec4d4b243f1bb5ca81
800000006557d0b9fb133a2aac2dc6a5704a3e1cc3cf218734e3e69fd75fd7b201
800000006420f33ae7c42309056f659a0a8040a8e88fede407385f16e3fa3d0d01
80bbbbbbe5aec1c599442efdd8718f07c3d5030e7d961d050b51a07fb34461252f
80bbbbbbd2f0e632e777c215ab201ac33b832f6e8677f2af287db85bca6d9861af
80b2b2612a2f3e546e9f4c5a086baa9ed1cfcc8644d979d6f4ede6883fcdfc4600
80b2b26123d959fe98927d86328f1634ba6be8aec4864bcc695ceca0585df91680
809c061d02148d896410c270484589335cf9695b716b3664f43e0c7f7f7e365b4a
809c061cac90ec0bdef7cf43b8cdf4cafaa3ef537776b3039e6a7d86e940e9c7ca
809c061b28ddb45790b8bbebeb8cb546bab00cbe9a5eed262e6edb12e55fdcd74a
809c061b286230eef09e03d63165443b04d990c09eb5d52aa54a4986bd207676ca
809c061b0240e31ef720f942d4a3efd5d16d150c922473851c6be032c84db194ca
809c061ad643c1d6692cb516b418a5af667fe4b25bed34db4cf9a8b73fae7f074a


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."
copper member
Activity: 1330
Merit: 899
🖤😏
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. 😉
legendary
Activity: 4424
Merit: 4794
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
copper member
Activity: 1330
Merit: 899
🖤😏
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.
copper member
Activity: 1330
Merit: 899
🖤😏
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.
copper member
Activity: 1330
Merit: 899
🖤😏
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.😉
Jump to: