## Can we increase the entropy of a hash by converting SHA-256 to SHA-1 and MD5?

In this context, ‘entropy’ basically refers to the probability of any particular guess about the content or value being correct.

If I tell you that I have hashed a single lowercase US English letter’s ASCII representation using SHA256, and that the hash is hexadecimal ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb, then the entropy of that value isn’t 256 bits, but rather closer to five bits (log2(26) ~ 4.7) because you only need to make at most 26 guesses to arrive at the conclusion that the letter I hashed was ‘a’. (For completeness, what I really did was ‘printf ‘a’ | sha256sum -b’ on a UTF-8 native system.)

The entropy, thus, can never be greater than that of the input. And the input is, at best, the initial hash, which has 256 bits worth of entropy. (It could have less, if the string you hashed has less than 256 bits of entropy and the attacker can guess that and its value somehow.) Each hash calculation can be assumed to be O(1) when the input size is fixed.

So by concatenating the SHA-1 and MD5 hashes of a string that is a SHA-256 hash, you can *never* get more entropy than 256 bits’ worth. All you are doing is making it longer, and possibly obscuring its origin.

Now, **in some situations,** using multiple hashes actually makes sense. For example, many Linux package managers use and validate multiple, different hashes for the same file. This *isn’t done to increase the entropy of the hash value,* though; it’s done to *make finding a valid collision harder,* because in such a situation the preimage or collision attack *must work equally against all hashes used.* Such an attack against a modern cryptographic hash is already difficult enough for most purposes; mounting a similar attack against several different hashes *simultaneously* would be orders of magnitude more difficult.