Return to Answer

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. (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)

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

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

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)

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

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. (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)

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

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

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)

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