Every good security program has a process for regularly reviewing its technical security controls for things like adequacy and correctness of operation. But one area of controls that is often overlooked is that of cryptographic hash functions. Sure, the key lengths used for your cryptographic tools for data at rest and in transit probably get looked at every so often, but hash algorithms are like the red-headed stepchild of the family. Fact is, they should be reviewed right along with the rest of your crypto, probably every two to three years or so.
First, though, a quick recap on hash functions (and they have nothing to do with a fatty breakfast dish). Hash functions are best understood as one-way encryption algorithms – easy to do in one direction, but really hard to do in reverse. These functions take some variable length input, like a document file, and spit out a fixed length string of typically 128 or 160 bits. A secure hash function makes it really hard (meaning computationally infeasible) to find two input messages that would result in the same hash value (known as a “collision”), and to determine the input message from a given hash value. It also means that any change in the input message would result in a completely different hash value.
The main uses of hash functions are:
- Verification of file integrity: by calculating a baseline hash value of a file or message, one can detect any changes down to the single bit by comparing a newly computed hash value to the original. If the hashes don’t match, you can be sure the file was changed.
- Creation of unique “fingerprints” of files in a repository for version control
- Secure storage of passwords: the password supplied by a user when logging in is hashed and compared to the stored value.
- Digital signing of a message: a hash of the message is signed, rather than the entire original file or message.
The most common cryptographic hash functions in use today are SHA-1 and MD5. Researchers have found weaknesses in these functions, however, meaning that shortcuts may be possible for an attacker seeking to generate a modified file that hashes to the same value. MD5 in fact, can now be trivially compromised with only a laptop. SHA-1 still has some life left in it (although not much), but NIST has recommended that federal agencies begin planning to replace it by 2010. Practically, these weaknesses means that an attacker could forge a digital signature or certificate, although it would take some considerable effort to do so.
So what do organizations using these algorithms in their software need to do?
- Build and maintain a list of uses of encryption and hash algorithms in the enterprise, including key lengths, validity periods, and required assurance levels.
- Develop a process for regularly reviewing the industry research literature for progress in cryptanalysis, and new attacks against commonly used algorithms. Annual or biennial review should be adequate.
- When algorithms or certain key lengths are reaching sunset stage, identify from your list all the places they are being used and the required assurance (for purposes of prioritizing your updates).
- Consult with your vendors to determine support for updated algorithms, and obtain new software as needed.
- Issue new internal guidance and educate your user base on the need to begin specifying and using the updated algorithms.
- Deploy software with updated algorithms (after extensive testing, of course, but you know that).
“Yearly Report on Algorithms and Keysizes (2006)”, by ECRYPT, the European Network of Excellence in Cryptology.
U.S. NIST’s Cryptographic Hash Project