Return to Answer

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of a practical hash function such as SHA-256 is often limited even though the input space is unlimited. SHA-256 has a ridiculously large input message size ($2^{64} - 1$ bits). This is mainly due to the algorithm including the encoding of the amount of bits that are hashed. This will lead to an average of $$2^{2^{64} - 1} \over 2^{256}$$ collisions for each output value of SHA-256.

It should however be computationally infeasible to find a collision: two messages that hash to the same output. This is often the first property to fall if the hash function is broken: collisions have been found of both MD5 and SHA-1, for instance. Finding another input message for an existing hash is much harder, this is known as a pre-image attack.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are supposed to be one-way functions. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input equally. Note that we cannot prove that (commonly used) hash functions are indeed irreversible; it is just that every possible attack doesn't seem to apply for secure hash functions.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash comparison or signature verification.

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of a practical hash function such as SHA-256 is often limited. SHA-256 has a ridiculously large input message size ($2^{64} - 1$ bits). This is mainly due to the algorithm including the encoding of the amount of bits that are hashed. This will lead to an average of $$2^{2^{64} - 1} \over 2^{256}$$ collisions for each output value of SHA-256. Other hash functions such as SHA-3 don't have this limitation and do allow an infinite message space. In that case it is very likely that there are infinite amount of messages that have the same hash value for that specific hash function.

It should however be computationally infeasible to find a collision: two messages that hash to the same output. This is often the first property to fall if the hash function is broken: collisions have been found of both MD5 and SHA-1, for instance. Finding another input message for an existing hash is much harder, this is known as a pre-image attack.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are one-way functions by definition and by design. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input equally.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash comparison or signature verification.

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of hash functions is limited, but to a ridiculously large input message size ($2^{64} - 1$ bits), this will lead to an average of $$2^{2^{64} - 1} \over 2^{256}$$ collisions for each output value of SHA-256.

It should however be computationally infeasible to find a collision: a message that hashes to the same output. This is often the first property to fall if the hash function is broken though: collisions have been found of both MD5 and SHA-1, for instance.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are supposed to be one-way functions. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input. Note that we cannot prove that hash functions do provide this functionality; it is just that every possible attack doesn't seem to apply for secure hash functions.

Sometimes the security of hashes is put into question. There was for instance doubt if SHA-2 would fall to the same attacks as those found for SHA-1. This is one reason why SHA-3 was defined; however SHA-2 was found to be relatively secure against the attacks and SHA-3 is not used all that much yet.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash comparison or signature verification.

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of a practical hash function such as SHA-256 is often limited even though the input space is unlimited. SHA-256 has a ridiculously large input message size ($2^{64} - 1$ bits). This is mainly due to the algorithm including the encoding of the amount of bits that are hashed. This will lead to an average of $$2^{2^{64} - 1} \over 2^{256}$$ collisions for each output value of SHA-256.

It should however be computationally infeasible to find a collision: two messages that hash to the same output. This is often the first property to fall if the hash function is broken: collisions have been found of both MD5 and SHA-1, for instance. Finding another input message for an existing hash is much harder, this is known as a pre-image attack.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are supposed to be one-way functions. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input equally. Note that we cannot prove that (commonly used) hash functions are indeed irreversible; it is just that every possible attack doesn't seem to apply for secure hash functions.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash comparison or signature verification.

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of hash functions is limited, but to a ridiculously large input message size ($2^{64} - 1$ bits), this will lead to an average of $$2^{2^{64 - 1}} \over 2^{256}$$ collisions for each output value of SHA-256.

It should however be computationally infeasible to find a collision: a message that hashes to the same output. This is often the first property to fall if the hash function is broken though: collisions have been found of both MD5 and SHA-1, for instance.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are supposed to be one-way functions. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input. Note that we cannot prove that hash functions do provide this functionality; it is just that every possible attack doesn't seem to apply for secure hash functions.

Sometimes the security of hashes is put into question. There was for instance doubt if SHA-2 would fall to the same attacks as those found for SHA-1. This is one reason why SHA-3 was defined; however SHA-2 was found to be relatively secure against the attacks and SHA-3 is not used all that much yet.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash calculation or signature verification.

... its practically impossible to recreate a hash that for any foreseeable endeavor its fine or is there some element that I'm missing that reduces even that extremely low probability to zero?

The input space of hash functions is limited, but to a ridiculously large input message size ($2^{64} - 1$ bits), this will lead to an average of $$2^{2^{64} - 1} \over 2^{256}$$ collisions for each output value of SHA-256.

It should however be computationally infeasible to find a collision: a message that hashes to the same output. This is often the first property to fall if the hash function is broken though: collisions have been found of both MD5 and SHA-1, for instance.

Is there any design constraint that prevents a very powerful computer to back-calculate the original data from a hash? Or is it simply that the design is so complex that its simply a futile exercise to dream of such a large computer required for this task?

Yes, cryptographic hash functions are supposed to be one-way functions. By various techniques the input data is mixed in such a way that the calculation is hard to inverse, but that every bit of output still depends on every bit of input. Note that we cannot prove that hash functions do provide this functionality; it is just that every possible attack doesn't seem to apply for secure hash functions.

Sometimes the security of hashes is put into question. There was for instance doubt if SHA-2 would fall to the same attacks as those found for SHA-1. This is one reason why SHA-3 was defined; however SHA-2 was found to be relatively secure against the attacks and SHA-3 is not used all that much yet.

Whats stopping a hacker or malicious middle man to hack open the software program or library that creates this "hash" and then use that library to create hashes of his own or mislabel some target company's hash with his own pointing to their version of the file? Especially since many applications, languages, and developers use hashing independently. Whichever is most weakly secured, we can use that to take on the rest?

You would expect that such a change to the hash and tests performed on the hash will be found. If you can change the code that verifies the hash then yes, you could probably fool an application. Just like you can change code to completely skip the hash comparison or signature verification.