SHA-2 takes off, thanks to Heartbleed

Heartbleed is a great example of how spectacular security failures grab the popular imagination. There is another set of problems much less sexy and harder to fix: keeping standards progressing. As it happens, Heartbleed creates an opportunity to advance one of these standards: cryptographic hashes.

Because of their importance, a great deal of research, both black- and white-hat, is done on the important crypto functions. Over time, weaknesses will appear in even the state-of-the-art ones, sometimes just because computing power increases over time to the point where some brute force attacks become practical.

Hashes are a fundamental part of much of cryptography, and a weak hash makes for weak encryption. A hash function takes a block of data as an input and outputs a value of a defined size, known as the hash or digest. With a good hash algorithm, there is no way to take the hash output and learn anything about the input data, and even a small change in the input will cause a large change in the hash output. Cases where two different blocks of data produce the same hash may be possible, but they better be rare and, more importantly, unpredictable.

The current dominant encryption algorithm is SHA-1 (Secure Hash Algorithm), and is so designated by NIST, which sets these standards. SHA-1 (which, incidentally, was designed by the NSA) replaced an older algorithm MD5, which had been hopelessly compromised. Even though you still see MD5 used for some purposes, its use in critical applications, like SSL/TLS certificates, has been almost eliminated.

And now NIST says that the time has come for SHA-1 to be replaced as well. The new guidance is in spite of the fact that only theoretical attacks have been shown. There is SHA-2 that uses the same algorithm as SHA-1, but different input and output sizes. In fact, SHA-2 is a series of SHA options designated by the size of the generated hash: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 (the last four use a larger input block and more internal state). SHA-3, which was recently approved but remains unimplemented, uses a new algorithm.

Microsoft has announced that, as of January 1, 2016, they will no longer accept certificates that use SHA-1 into their root certificate program. On that same date, Windows will stop accepting as valid any code-signing certificate using SHA-1, and one year later they will stop accepting SHA-1 for TLS/SSL certificates. Thereafter, SHA-2 will be required for any new certificates if you want them to work with the Windows ecosystem. Microsoft is giving the industry a long time to adjust. They're not giving it because there's any reason to believe work needs to be done. Even Windows XP, as of SP3, supports SHA-2 [Corrected; used to say SHA-1].

Back to Heartbleed. One implication of Heartbleed is that a very large number of TLS/SSL sites will be revoking their old certificates and replacing them with new ones. Why not take the opportunity to move on to SHA-2?

Perhaps others have thought of this already. I asked Netcraft, the Internet intelligence firm that constantly scans web servers all over the Internet, partly for a running survey of SSL sites, what percentage of sites on the Internet use SHA-2, and whether there has been a spike in adoption since Heartbleed. The answers are seven percent and "yes," although from their most recent graph, just below, it looks like SHA-2 adoption started to pick up at the beginning of the year, well before Heartbleed.

My own unofficial survey of about 20 important web sites with TLS support found three with SHA-2 as a hash function: Apple.com, Twitter.com, and nist.gov — all with SHA-256.

Perhaps we should just file this in the "Never let a good crisis go to waste" cabinet. It's somewhat ironic that Microsoft itself and many of its customers who use Windows, and were therefore not vulnerable to Heartbleed (well, with limited exceptions), won't feel the same urgency to move their use of hash standards forward that OpenSSL users feel.