So, I was having this weird thought. If the checksums(MD5 or SHA...) are unique to any file and are modified if any part of the file is edited, why cant the checksums be decoded back to get the original file? That is if I want to send a large(say 700MB) video, instead I could send just the hash and the file be decoded locally in my friend's computer. I know the thought is stupid, but is it possible by any chance? Or am I missing some thing here? And forgive me if I'm wrong, I ain't a professional.
4
-
$\begingroup$ There are many plaintexts mapping to a single hash. (In fact, if the input length is unbounded, there is at least one hash which has an infinite set of corresponding plaintexts.) Now the hard part in your proposal (besides inverting the hash function, which is considered infeasible for good cryptographic hash functions) is determining which of the possible plaintexts is the right one. Just a hash is insufficient information for this. $\endgroup$– yyyyyyyCommented Aug 2, 2015 at 13:50
-
$\begingroup$ Oh, I was thinking that hashes are unique to a file. Heck my ignorance. :( $\endgroup$– SriramCommented Aug 2, 2015 at 13:54
-
$\begingroup$ Hashes are (ideally) computationally unique to a file, that is, nobody should be able to obtain two different files with the same hash — perhaps that's where your confusion stems from. But this does not imply anything about the mathematical existence of such collisions, which is a necessity for any function mapping long strings to short strings. $\endgroup$– yyyyyyyCommented Aug 2, 2015 at 14:00
-
3$\begingroup$ You cannot recunstruct an arbitrarily long value from a fixed size hash because of the en.wikipedia.org/wiki/Pigeonhole_principle $\endgroup$– Z.T.Commented Aug 2, 2015 at 14:07
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
If the checksums (MD5 or SHA...)
First things first: there is a BIG difference between a checksum (aka “cyclic redundancy checks” like CRC32) and a hash (aka “cryptographically secure hash functions” like MD5 and the SHA families).
The biggest difference between checksums and hashes is that checksums are neither build, nor meant to be cryptographically secure. (Checksums are mainly used for error detection; eg after file transfers.) To get a better understanding of the different categorisations, you might want to take a look at Wikipedia: List of hash functions.
Anyway, let’s get to the core of your question…
Is Checksum to file back decoding possible?
No, that’s not possible. Neither a checksum, nor a cryptographically secure hash enables you to rebuild the data it was created from. The reason is simple: both hashes as well as checksums are one-way functions. They “compress” the information down to a level that makes it infeasable to revert them.
In fact, you could almost compare them to lossy compression algorithms which compress information beyond the point of recoverability, but in a way that even a single bit change of the original file will result in a completely changed hash or checksum.
Especially when talking about cryptograhically secure hash functions like SHA2, SHA3, et al (MD5 is regarded not to be so secure anymore in all cases), you should note that an ideal hash function has three main properties:
- It is extremely easy to calculate a hash for any given data.
- It is extremely computationally difficult to calculate the data which was used to create a specific hash.
- It is extremely unlikely that two slightly different messages will have the same hash.
Here, “extremely difficult” practically tends to boil down a situation where “brute-force” is your only chance. So, the receiver of your 700 MB video file would need to create several thousands of versions of 700 MB files using random data, then hash that data and only if the hash fits your hash, the receiver would be sure to have a copy of the file you hashed.
Simpler said:
Creating a checksum or hash is very much different from a regular data-compression algorithm like ZIP/deflate. If you test things yourself, you’ll quickly notice that even the best file-compression program will not be able to shrink your 700 MB video file down to a few hundred bytes… for a good reason. Those programs need enough data to reconstruct the original file. A hash or checksum doesn’t offer any such “decompression” functionality as it isn’t meant to do that in the first place (see emphasised point of above property list).
Both hashes and checksums produce a (let’s just call it) “unique summary describing the data”, but they do not hold, contain, or are able to reproduce the original data.
$\begingroup$
$\endgroup$
If you have the hash of a 700MB file then to reconstruct the file you would have to generate random 700MB files until you found one which has the hash you were looking for.
There are two reasons why this wont work well in practice:
- It will take far too long to get lucky and find a file with the correct hash (the chance of it happening is so low that it should be called impossible)
- There may be multiple files which have the same hash
On the other hand the scheme can work in a modified setting. You can often recover short strings given their hash by brute force. Second, a server could be built that you can download a file given its hash (when it has it).
