What if a hacker creates a fake file with exact same hash value as original content? How does IPFS work to detect whether it's the right file or not?

Help
#1

Hi,

As I am new to NFTs, I’ve learned that the actual NFT digital content is stored in IPFS.
I’ve also learend that IPFS is safe because it uses HASH that if there’s one little change, the HASH value changes.

However, as there were many attempts in Blockchain as well, there are hackers who manipulate the time stamp and create the exact same HASH value with wrong file.

So, when that exact HASH with wrong file is distributed, how can IPFS detect which one is the original and which one is wrong file?

1 Like
#2

Files do not have timestamp metadata in IPFS

#3

In the Bitcoin case, it was a design bug: an important information (the date), what not included in the data to hash, so it could be forged. In the Bitcoin protocol, being able to forge the date was a vector for attack. In IPFS, the metadata is not included and not transmited. It is up to the client to create them, or obtain them by another mean. If you “wrap” your file in a directory, you may be able to transfer the metadata. But now it is the hash of the directory and the files inside, so the metadata are protected.

In short, all informtions that are transmited via IPFS or published to it are protected. An “IPFS hash” (aka a CID), maps to a precise string of byte, so IPFS is not affected by Bitcoin’s problem. (And to be clear, the Bitcoin problem wasn’t that there was an alternative file created with the same hash which is impossible, it was that some important data wasn’t covered by the hash and hence were forgeable)

1 Like
#4

If a hacker can create a file that has the exact same hash value as the “original” one, the hacker has either recreated the original file or found a hash collision.

1 Like
#5

note about IPFS and any content addressed storage too, if you place a “corrupted” file manually in a repository under a certain hash, the DHT will see you as provider and may ask you for the file, the same file can be transmitted to the client as if it is the right one however it won’t be shared with the same hash as the client will detect the mismatch.

what it means is that indeed this is a vector for (d)DoS attack as all verification is done on the client side, this one of the reason big file are “chunked” to mitigate the load when such an attack occurs as we can only detect things are wrong on the client side on any peer-2-peer network

In IPFS this approach for using the wrong hash / content is exploitable for short lived mutable and this give a speed advantage over the more classic blockchain mutability (as it requires no concensus or majority protocol)