Krdytkyu

No, there is no way to compress (or hash or encrypt or whatever) a 5 MB file into a 32 byte hash and then reconstruct the original file just from the hash alone.

This is simply because there are many more possible 5 MB files than there are 32 byte hashes. This means that, whatever hashing or compression or other algorithm you use, it must map many different 5 MB files to the same 32 byte hash. And that means that, given only the 32 byte hash, there is no way you can possibly tell which of those different 5 MB files it was created from.

In fact, the same thing happens already if you hash 33 byte files into 32 byte hashes, and then try to reconstruct the original files from the hashes. Since there are 256 times as many 33 byte files as there are 32 byte hashes, that already means that there must be several different files that have the same hash. With 5 MB files, it's many, many, many times worse yet.

So how can something like IPFS work, then?

Basically, it relies on the fact that even the number of possible 32 byte hashes is really huge* — much, much larger than the total number of actual files (of any length) that humans have ever created, or are ever likely to create. So, while we know that there must be many possible files that have the same 32 byte hash, the chance of actually finding two different files that just happen to have the same hash by chance is still so incredibly small that we can basically assume it will never happen.

(Also, cryptographic hash functions like SHA-256 are designed so that, hopefully, there are no practical ways to deliberately find files with the same hash more efficiently than by just hashing lots of files and hoping against all odds for a random collision.)

This means that if we have some kind of a (possibly distributed) database containing a bunch of files and their SHA-256 hashes, then we can be pretty sure that it will never actually contain two files with the same hash, even if that's theoretically possible.

Thus, as long as we have access to such a database, we can use the hash of any file in the database to look it up, and be almost 100% certain that we will only get one matching file back, not two or more. Technically, the probability of getting multiple matches is not quite exactly zero, but it's so incredibly small that it can be safely neglected in practice.

^{*) In fact, it's 28×32 = 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936.}

No, it's not possible to retrieve the original input of a hash, because the input of a hash can be of almost any size (less than 2'091'752 terabytes).

But the hash value is always a fixed length, i.e. a SHA-256 has always a 256-bit value. That's why there are multiple inputs that have the same hashed value, see Pigeonhole-principle.

That's also the reason for why you can never retrieve the original input, because you can never be sure that this really would be the original input and not some other input that happens to have the same hash-value.

The other answers are correct, there is no way to recover data from a hash.

From your phrasing, I think that this may be an instance of an X-Y problem: you need very aggressive lossless compression, and hashes plus some way to undo them are the closest thing you know of.

Accordingly you might look into an abuse of fractal compression: oversample your bitstream such that fractal compression gives an image that results in the original bitstream after a downsampling pass. In principle this can trade the length of your transmitted message for potentially large amounts of pre- and post-computation - you only have to transmit the coefficients and stopping conditions of your fractal calculation and the program that understands them, which could be as small as a few kilobytes, but the search to find those numbers is computationally hard.

Simple information theory shows that this is not possible. For any given hash value, there's an infinite number of files that produce that hash (assuming there's no arbitrary limit on the input length). It's possible(*) to produce a file that produces the same hash, but because information has been discarded, there's no way to say whether or not it's the file that was originally hashed - all of those infinitely many inputs are equally plausible.

(*) "possible" in a theoretical sense - the role of a good cryptographic hash is to make such reconstruction hard - preferably as hard as randomly guessing until a match is found. More rigorously, we say that it should be computationally infeasible for an attacker to create a matching input.

If you have a suitably small and finite set of files, that just coincidentally have unique hashes, then yes you can derive the file from the hash, using the hash as a key.

To guarantee that hash collisions do not occur for your "library" of files, you can reserve a "scratch area" (a gap somewhere) for tie breaking purposes and populate it with arbitrary values that produce a new, unique key for the whole file, which has now changed.

It is probably easier just to use a synthetic key from the outset a la Library of Congress or ISBN.