# Safe MD5 digest

So I've heard that MD5 is broken because it's possible to engineer collisions. So instead we should use, say, SHA256. The problem which SHA256 digests is that they are long. So I've come up with this:

function mdsha( input ) { return md5( sha256( input ) ); }


So I can retain MD5 digest lengths and avoid malicious collisions.

Is my scheme sound?

• It depends. Do you consider $2^{64}$ SHA-256 evaluations to be infeasible (given that the current complete bitcoin mining network does something in a similar scale every second)? If not this scheme isn't sound. – SEJPM May 9 '16 at 19:06
• Why is it 2^64? MD5 digests are 128 bit... – John Elliot V May 9 '16 at 19:23
• @JohnElliotV Collision resistance on the other hand is half the amount of bits because of the birthday problem. That's why hash function outputs are generally double the size of keys for symmetric ciphers. E.g. take a look at keylength.com / ECRYPT II recommendations. – Maarten Bodewes May 9 '16 at 19:26
• I was thinking that I'll use the last 160 bits (40 hex chars) of a SHA256 digest for my purposes. Would that at least be more secure against malicious collisions than MD5? – John Elliot V May 9 '16 at 19:29
• Absolutely. As indicated, it's more standardized to use the first 40 characters though (i.e. the first 160 bits). Note that MD5 hashes are 128 bits, not 160 bits, so you would go outside of MD5 output size. SHA-1 uses 160 bits. – Maarten Bodewes May 9 '16 at 19:31

• The last paragraph is important. 128-bit hash means ~$2^{64}$ collision attack, which is expensive, but plausible. One option to increase collision resistance would be an iterated hash. – otus May 9 '16 at 19:23
• @JohnElliotV H(H(H...H(M)...)) where the number of hashes is large, e.g. 10K or 100K. The idea is that an attacker also needs to perform all those hashes, but $2^{64}$ times to perform the attack. Needless to say, this will cost you CPU cycles. – Maarten Bodewes May 9 '16 at 19:50