Topic: REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other (Read 40724 times)

Hash alone is not enough, if he finds a valid private key that has a public key with the same hash as the hash of that address's public key then he can spend them and no one can stop him.

I was curious about a question that came to my mind.

I saw a dead wallet address from 2010 which holds about 30,000BTC. Pretty sure either owner is already dead by now, or he's now at least 50 years old. Anyways...

What would happen if someone miraculously hit the jackpot and successfully managed to generate the same hashes that produces the same address that holds the coins?

Can he sells the coins and just change from nothing to Billionaire overnight? Could we try to lock and prevent him from selling the coins that he stoleny illegally took and held?

You use identical message. In binary, it is "00000001". In hex, this implementation for some reason use padding to 8-bit values, so better switch to binary values. In general, for every message you have at least one 512-bit block, for example for your message it looks like that:
Here, you can see that the raw data is "01", then you have "80", because of that added "1" bit, and then you have a lot of zeroes (padding), and "8" in the end, as the size of the message in bits (not bytes, for that reason you can hash single bits).

Read back the previous pages, I have explained how to find them with 100% certainty, there is no other proof that I know of, and what I have explained is good for sha256 and rmd160, I was unable to even understand what does (sha256(rmd160) mean, but I know what does sha256 double collision mean, having 2 different inputs generating 2 different first hash but having identical second hash, that's a bit (very) hard to construct a sure method.

However, every problem has not one but many solutions, and in order to find them you need no computational power at first, what you need is to come up with an algorithm to perform a task and then you let the computer to do the heavy work. For now the safety of all hash functions and elliptic curves depend on DLP.
~dig.

No, it doesn't exist. If it does, then all the news would say it. If you insist, show me the proof.

They already exist, we just don't know whether they have been found and are being exploited or not, however if they become publicly known then we'd be sure they can be exploited, thus requiring a major change which will render all miners useless, this is what worries me.

But even if a collision related to sh256 or double sha256 were found, this would not be a problem for Bitcoin.  not for wallet security and not for mining.  Right?

Guess that explains why the following inputs have the same hash:
"ffffffffffffffffffff000000"  ,  "ffffffffffffffffffff00000". =
"02de980e731d160a92b4f41fe07d1b2763f167906db488e4cd380f3936e51ff4". The software I use is a broken open source implementation.😉

Whatever you use to calculate hashes is broken and deletes leading nulls.


SHA-256 can technically be used on an arbitrary number of bits that don't divide by 8, but in practice no implementations ever use that feature, and only do full byte sequences.

Question regarding hash functions:
Do they all operate based on 2 character set hexadecimal or we can hash a single hex character as well?
I'm asking this because I have found 2 strings with only 1 character difference having the same digest, maybe it's a bug?
Like if they are not supposed to give you any hash for a single bit, then all the 16 bit hex chars used bit by bit should never produce a hash while they do, so why is it when I use a 30 long char hex string and a 31 long char string they both produce the same output?

*For example: "1234567890" and "12345678901" give me the same output.

*=Fake example.

Real example: "1" and "01" give this "4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a"

Am I missing something?
And please don't tell me the algorithm pads a 0 to 1 when we only use 1 as input, because I have 2 strings not starting with a 0 but have the same hash.

First of all, define "better". SHA-512 probably have better collision better resistance due to longer output, but SHA-256 have shorter output which save bandwidth/storage which have some importance when using Bitcoin. And if we're looking for better hash algorithm, we probably should look for to more modern/secure standard rather than SHA-2 standard (such as SHA-256 and SHA-512).

is SHA512 better than SHA256? if yes, why don't we use that?

If someone found a SHA256 collision it would be all over tech news. The only collision so far is the SHA1 one, where someone simply copied the collision published by Google at https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html.

If you hash the public key of the address above, you will get [5], if you hash [6] you'd still get [5]. And I don't know how we could spend the funds if it was loaded, I'm not trying to find people's private keys, this is about hash collisions.

---

Not applicable to SHA-256, I just exercised the method to prove avalanche effect  is an illusion, Satoshi inadvertently created an algorithm that can be used to draw a map of all SHA-256 collisions, it's like a knife cutting it's own handle.
This is as far as I am willing to go on this matter, I have decided to stop working on it and will not publish further findings, telling people 5x5=25 makes it easy, but showing them "25" makes it hard for them to figure out the proper equation. I need to confuse the outsiders, while the insiders know what 5-5-2-5 means.

---

No, we are just talking about how to easily find them, one way is brute force, other way is beyond my comprehension, you should read "vjudeu's posts to know what I mean.😉

---

Even if we find a collision, we must not publicly disclose it to the world, instead we should convince the world that the algorithm "is no longer secure".
If anyone is interested to further discussing the issue, come and visit my special penthouse at digaran's tower.

i haven't had time to go through all the replies here. But did anyone successfully find the collision?

You mean the "avalanche effect"? That still doesn't change the fact that the probability of finding a collision is only high when you compute an unimaginably high number of hashes.
Our input is also not infinite, it is finite if we are talking about public key hashes (points on the curve which is a subgroup and finite). Although since the number is too big, it could be seen as infinite and impossible

I honestly didn't quite get what you said in the first part so I decided not to comment on that and let others do.

Let's pretend there was funds in the address in your example 1ArWUwF2WfPnDubReohn2vtPodfPpG5Evq ,  still they won't be able to move those funds since they don't know the private key of that address, the steps you provided is not enough to do that.

Except they have chosen the same atom due to the fact of reverse snow ball effect on SHA-256, where having an infinite combinations of different data as input will drastically increase the probability of collisions.

People always wanted to see actual collisions, I merely satisfied the general public's desire, mine as well.
I'm glad you had no comment/ mistake correction on that.

Except that "long enough" in this context means thousands of years since there are a little less than 2²⁵⁶ public keys and you need to check about 2¹⁶⁰+1 of them to find a collision. Something that is not possible with existing hardware or in our lifetime.

That would be like saying 2 people can choose the same atom in the universe....

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.