Is using the concatenation of multiple hash algorithms more secure?

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.

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 (http://programmers.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. (http://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. (http://stackoverflow.com/questions/7407835/512-bit-hash-vs-4-128bit-hash)

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