Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:00 PM
Connect Directly

NIST's Hash Algorithm Refresh Possibly Premature

Security expert Bruce Schneier says there's really no need for the upcoming SHA-3 standard

The National Institute of Standards & Technology (NIST) is set to announce the winning hash algorithm that ultimately will become the next-generation industry standard, SHA-3. But security expert Bruce Schneier, whose own solution is among the five finalists, says there's really no need for a new hash standard right now because the old one is doing just fine, thank you.

After a spate of SHA-cracking targeting earlier versions of the standard, NIST was under the gun to keep the algorithm strong. "When we started this process [in 2006], we did think the whole SHA family's days were numbered," Schneier says. "But then the SHA hacks stopped."

The most recent version of the algorithm for "fingerprinting" messages and files, SHA-512, so far has held up. That, and the fact that none of the finalist versions are exponentially better solutions means it makes more sense to stick with SHA-512 for now, Schneier says.

"They're all OK, but there's no compelling reason to switch," he says. That's in contrast to the Advanced Encryption Standard (AES), which, when it was announced, was widely adopted to replace the slower and outdated Data Encryption Standard (DES).

NIST was scheduled to announce the winning specification for SHA-3 in the second quarter of this year, but hasn't done so yet. The submission and selection process began in late 2007, and some 64 entries were part of the first round of the competition. The algorithm converts messages into shorter message digests that can be used in digital signatures and message authentication, for example.

[Researchers with IBM highlighted the deteriorating state of password security in the IBM X-Force 2012 Mid-year Trend and Risk Report. See Bashing The Hash: IBM X-Force On Password Follies.]

Schneier, who blogged about SHA-3 today, says his submission, Skein, is among the finalists. But even so, he still believes SHA-512 is sufficient and doesn't require a substitution right now.

That doesn't mean SHA-512 won't ultimately be broken. "I don't know if we have tried hard enough to break SHA-512," he says. And just because it hasn't happened yet doesn't mean there hasn't been multiple attempts, he says.

Robert Graham, CEO of Errata Security, concurs that SHA-512 is doing the job today. "SHA-512 is doing well. There are some threats to it, but that's just because it's really well-understood," Graham says. "SHA-3 won't be well-understood -- there is a good chance that a couple years after adoption, there will be just as many threats as with SHA-512."

Even so, says Graham, SHA-512 is not widely adopted today. "I don't see it in hardware, and software has become incredibly modular, making it easy to plug in SHA-3. After a couple of years, SHA-3 will be just as widely spread as SHA-512," Graham says.

He says the benefits of faster hashing and other features with SHA-3 will ultimately make it worth the transition.

Schneier, meanwhile, says he'll recommend sticking with SHA-512 for now. "...None of the SHA-3 candidates is significantly better. Some are faster, but not orders of magnitude faster. Some are smaller in hardware, but not orders of magnitude smaller. When SHA-3 is announced, I'm going to recommend that, unless the improvements are critical to their application, people stick with the tried and true SHA-512. At least for a while," he wrote in his post.

So what about Skein? "Well, maybe there's one reason NIST should choose Skein. Skein isn't just a hash function, it's the large-block cipher Threefish and a mechanism to turn it into a hash function. I think the world actually needs a large-block cipher, and if NIST chooses Skein, we'll get one," he wrote.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...