What the SHA-1 retirement means for you

On Wednesday December 15th 2022, NIST, the National Institute for Standards and Technology announced the retiring of the SHA-1 secure hash algorithm (also called a hash function). Published in the document FIPS-180-1 by NIST as a standard in 1995, SHA-1 became the workhorse among secure hash functions. SHA-1 is used everywhere: in storage devices to detect duplicates and check integrity; in communication protocols; for authentication and tokens; etc. In our work at Assured auditing and testing customer applications and solutions we see SHA-1 being used everyday.

Now it is time to start to plan for and to start working on migrating to another secure hashing function. This is not the first time NIST retires an algorithm. DES, the venerable block cipher was retired and withdrawn in 2005. For DES, NIST allowed a fairly long grace period. But for SHA-1, NIST express a level or urgency:

“We recommend that anyone relying on SHA-1 for security migrate to SHA-2 or SHA-3 as soon as possible.” —Chris Celi, NIST computer scientist

What does this mean for us?

In short: replace all instances where SHA-1 is used with another secure hash function. Often the major problem when migrating algorithms is not phasing in a new algorithm, the big problem is phasing out the old ones. Running two different algorithms in parallel also means more compute and storage resources are required. For example, if we're storing hash digests for files we now need to store at least double the amount of information. If protocols are using SHA-1, this means the protocol and all nodes communicating using the protocol have to be updated.

What should we use instead?

Fortunately, several of the alternatives to SHA-1 have been standardised since many years. There are several mature and well tested implementations, including support in many processors and microcontrollers (MCUs). Many standard communication protocols (for example TLS) have cipher suites which use these hash functions and libraries implementing TLS and other protocols support these functions, too.

NIST provides several alternatives. The SHA-2 hash functions including SHA-256 and SHA-512 are commonly used, where SHA-256 is what is normally used instead of SHA-1. One issue with SHA-256 is that it is slower than SHA-1. However, on many modern 64-bit architectures SHA-512 is often faster than SHA-1. The truncated version of SHA-512 called SHA-512/256 may in these cases be a good choice. This version provides protection against length extension attacks. NIST has published the SHA-3 hash function which works well and provides good performance, especially in hardware implementations.

An alternative to NIST standards is the BLAKE2 hash function. This function is faster than SHA-1, is mature and available in many implementations. It provides additional functionality such as keyed hashing and does not suffer from length extension attacks.

The gist of all this is that there exists several alternatives. Some of them are designed to be drop-in replacements. There are also good implementations available in libraries and even in the CPU or the operating system. There is no need to spend time implementing these algorithms. And especially not invent a new algorithm

Are there cases when we don’t need to migrate?

Similarly to the older and today very much broken and insecure hash function MD5, SHA-1 is used in constructions which still are secure, even if the strength of the underlying hash function has been weakened. One such typical construction is the HMAC hash based message authentication code. In these situations, the need to change is less urgent. The usage may be phased out when the product/system reaches end of life.

One argument sometimes raised is that SHA-1 and MD5 are not used for security related hashing. But in that case one could instead have used a much, much faster hash algorithm. Compared to algorithms like xxHash, MurmurHash3 or SipHash, SHA-1 is an order more expensive to compute.

What to do now?

We recommend to start by investigating if, where and how SHA-1 is being used in existing products, systems and services. What would happen if SHA-1 would be replaced with another function? What are the life cycle plans for the product/system and how is it updated? In short: what would the consequences be and what would it cost? Also, talk to suppliers and vendors and ask about their analysis and plan for migration.

What we strongly recommend not to do is specifying usage of SHA-1 in new systems and products. Even if it would be used in a setting that would be secure (for example in HMAC), you would create a dependency which makes it harder to remove SHA-1 in the future.

If you have questions about SHA-1, how to perform the analysis or choosing the right hash function to migrate to, don't hesitate to contact us at Assured.