Is using the concatenation of multiple hash algorithms more secure?

Question

Is it more secure in practice to use the output of multiple hash algorithms instead of a single one (assuming that the output size is the same)?

By secure, in this context, I mean protecting against both collisions and function reversibility.

One particular example would be using 128 bits from SHA-512 plus 128 bits from MD5 instead of using 256 bits from SHA-512.

My intuition is that, theoretically, this would weaken the function, because there are known attacks against MD5 which, effectively, would reduce the output size of the combined function. However, in practice, is it more difficult to find a collision/inversion for both algorithms at the same time - because it'll involve additional theoretical work as opposed to using existing (or upcoming) published ones?

EDIT:

To clarify, I'm simply asking about the basic properties of irreversibility and collision resistance - not about any particular use of hash functions, such as key derivation from passwords (there's excellent coverage about that in other questions) or using the output as unique identifiers.

Another way to phrase this would be "is a hash function defined as the concatenation of two other hash functions better than those?". Also, I'm (somewhat) aware that, information theoretically, it can't possibly be.

Answer 1

From the standpoint of collision-resistance (finding two colliding messages) and second-preimage-resistance (finding a different message colliding with a given one), the concatenation of multiple hashes is at least as secure as the strongest of the hashes (Proof: for any of the two properties, any attack that breaks the concatenation can be turned into an attack that breaks each hash. For example, hypothetical colliding messages for the 640-bit MD5||SHA-512 also collide for SHA-512, thus if SHA-512 is collision-resistant, then MD5||SHA-512 is collision-resistant).

From the standpoint of finding a message hashing to a given value ([first-]preimage resistance), or finding an unknown (possibly short or low-entropy) message known to hash to a given value (the situation in password hashing), it is prudent to consider that the concatenation of multiple hashes is insecure (possibly much worse than any of the hashes). We can construct hashes so that each is individually resistant to finding an unknown message (chosen randomly in some set too large to explore) from its hash, but the concatenation is totally weak against that.

For many iterated hashes including all Merkle-Damgård hashes (thus MD5, SHA-1, the various SHA-2), using the concept of multicollisions, it can be shown that the concatenation of multiple hashes is not much more secure against collisions than the strongest of the hashes. See Antoine Joux: Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions, in proceeding of Crypto 2004.

The above article strongly suggests that among using 128 bits from SHA-512 plus 128 bits from MD5 (or) using 256 bits from SHA-512, the later is much safer. The only assurance we have about the former is that it is not worse than SHA-512 truncated to 128 bits, which can be attacked in about 2⁶⁴ hashes, when we expect the later to require about 2¹²⁸ hashes to attack.

Answer 2

You don't mention what you're using the hashes for, but it appears likely that your intent is to use if for password verification.

So, the first issue to clear up is the concern that a given algorithm might be found to be susceptible to collisions. Collisions are not a threat to password hashes, and even if an algorithm were susceptible to collisions, that doesn't weaken it for the purpose of password hashing. For password hashing, we're worried about pre-image attacks instead...Being able to find the input that was used to create a given hash.

Today, the primary mechanism to attack password hashes is a dictionary-based brute-force attack. You hashes as many possible inputs you can, as quickly as you can, to determine which input results in the hash you're trying to match. Thus, the most desirable feature of password hashing function is slowness. You want to ensure that it takes as long as possible for an attacker to test the inputs required to find the correct one.

So, now that we understand what we're looking for, let's take a look at your proposal.

If you hash the password twice, with SHA-512 and MD-5, and truncate to 128 bits of each, and concatenate them together, for all intents and purposes, you're giving the attacker two hashes to work with. In many cases, the security of a hash isn't terribly reduced by truncation, as long as the resulting length is reasonable, which 128 bits likely is.

This means that you're taking two fast hash functions (SHA-512 and MD-5 are both far too fast to be effective password hash algorithms) and offering the attacker the opportunity to choose which one they would like to use to crack your hash. In this case, they're certainly choose MD-5, and feed inputs into it, truncate the hash to 128 bits, and match it to the MD-5 portion of your hash, and as soon as they have the match, there's near 100% certainty that they also have the value they need to compute the SHA-512 portion of the hash on a single try.

So, not only does this specific construction not improve security, but it actually rather significantly cripples it instead. While there are other potential constructions that could prove to increase security, it's not a simple matter to get it right, so if you really want a reasonable assurance of security, use a proven construction like bcrypt with a reasonable work factor.

Answer 3

Referring to the first few paragraphs in this article: https://crackstation.net/hashing-security.htm

If you are thinking of writing your own password hashing code, please don't!

I understand that you don't consider writing your own hashing code, but rather use multiple of standardised ones to seamingly increase security. This will, however, give you no or little advantage.

Ratchet Freak (https://softwareengineering.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times) points out that your hash function would only be as secure as your weakest function in the chain. Weaker algorithms are also known to collide more often, and thus potentially increasing the risk of collitions - making your overall security less.

Furthermore, this will as mentioned decrease entropy instead of increasing it.

There is also no reason why you would rather go ahead and implement two different methods and combine them - in practice there will be none or very little gain. 256 bit SHA-512 will be stronger than two merged 128 bit hashes - since the entropy is increased and overall stronger. MD5 will contain a lower entropy and therefore decreasing the security.

EDIT

To clarify the answer:

SHA-512 is stronger than MD5 (for the bit count that was mentioned, 256 and 128) for the mentioned case. MD5 is more likely to result in collisions. (https://stackoverflow.com/questions/2117732/reasons-why-sha512-is-superior-to-md5)

128 bit MD5 and 128 bit SHA512 vill only be as collision-resistant as the weaker of the two - the 128 bit MD5. (https://stackoverflow.com/questions/7407835/512-bit-hash-vs-4-128bit-hash)

EDIT

As pointed out by fgrieu down in the comments, this turns out to be not true.

As an illustration, we can find new MD5 collisions at high rate, but there is no known collision for SHA512 truncated to 128 bits, thus no known collision for the 256-bit concatenation of MD5 and SHA512 truncated to 128 bits. -fgrieu

The only way I could see this being beneficial is protection against Rainbow Tables, which probably wouldn't be prepared for your hash concentration. Instead of concentrating the hashes, salts should be used. But since you were not interested in the password security side of things ("I don't have any particular intent, and I was hoping to treat it as simply another hash function")

Points brought up in the comments.

• To reduce collisions, concatenation is better (because you need collisions on both hashes simultaneously). To reduce preimage attacks, chaining is better (because you need to reverse both hashes in sequence). - Ben Voigt