My MD5/SHA2 Function

A lot is being written these days about vulnerabilities in various cryptographic hash functions. Often, the weakness involves the ability to devise two different files that yield the same hash.

Imagine this scenario: you download a popular utility from the Internet and take the time to check it's MD5 hash, comparing it to the published value. Since they match, you are pretty certain you have the original, unaltered file. Well, because of the known weakness in MD5, you can't really be all that sure. Maybe the original file has been replaced with a malicious file that yields the same hash.

Although it would be possible to keep switching to newer, more secure hashing algorithms, this presents a problem. Do you rehash every file out there with a new routine? What about existing systems and users--how will everyone coordinate the switch?

One solution would be to adopt a standard of using multiple hashes to verify a file. For example, you could generate both an MD5 and a SHA-224 hash for each file. This same approach could be used by programs that store hashes of important system files to detect tampering. Just store both hashes, and check them both. The possibility of coming up with a malicious replacement file that yields both the same MD5 and the same SHA-224 hash is ludicrous. Let's call our new hash function MD5/SHA2.

At some point in the future, this approach might be considered insufficient. At that time we can add a third hash function to the mélange. Existing 2-hash implementations could remain in use, and new files would receive the added security of the third hash. (A likely third choice could be something like RIPEMD-160, giving us the MD5/SHA2/RIP1 hash standard).

By specifying the addition of new hashes instead of replacing the old ones, we improve backwards compatibility while improving security. This also sidesteps the inherent risk in switching to a new standard--new standards need a great deal of time to prove they are strong. By appending them to older, known standards, we mitigate this risk.

Users or implementations that can't, or choose not to, use 2 or 3 hashes can just verify against the first hash and be done with it. For added security, verify the additonal hashes.

(I know, all of us check the MD5 hash of the files we download from the Intarwebs. Riiiiight.....)

Documentation for MD5, SHA-224, RIPEMD-160

Author: Tim Daniels
Article Hashes:
MD5 - 5fbe2248b1dfb7012b82e6913b85cfed
SHA-224 - 41f58d49189124e2e8837a93c54513a43637174e20dd88c65abbe3c2
RIPEMD-160 - 307e9e17d4fbfb060015b706bc2a000d778f3455


Mitsubishi's new privacy display