60

On the 2nd of October NIST decided that SHA-3 is the new standard hashing algorithm, does this mean we need to stop using SHA-2 as it is not secure?

What is this SHA-3 anyway?

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196

4 Answers4

59

The SHA-3 hash competition was an open process by which the NIST defined a new standard hash function (standard for US federal usages, but things are such that this will probably become a worldwide de facto standard). The process was initiated in 2007. At that time, a number of weaknesses and attacks had been found on the predecessors of the SHA-2 functions (SHA-256, SHA-512...), namely MD5 and SHA-1, so it was feared that SHA-256 would soon be "broken" or at least weakened. Since choosing and specifying a cryptographic primitive takes time, NIST began the SHA-3 process, with the unspoken but clearly understood intention of finding a replacement for SHA-2.

SHA-2 turned out to be more robust than expected. We do not really know why; there are some half-baked arguments (the message expansion is non-linear, the function accumulates twice as many elementary operations than SHA-1...) but there is also a suspicion that SHA-256 remained unharmed because all the researchers were busy working on the SHA-3 candidates. Anyway, with SHA-2 doom being apparently postponed indefinitely, NIST shifted its objectives, and instead of choosing a replacement, they defined a backup plan: a function which can be kept in a glass cabinet, to be used in case of emergency. Correspondingly, performance lost most of its relevance.

This highlights the choice of Keccak: among the competition finalists, it was the function which was most different from both SHA-2 and the AES; so it reduced the risk that all standard cryptographic algorithms be broken simultaneously, and NIST metaphorically be caught with their kilt down.

Let's not be hasty: not only is SHA-2 still fine (both officially and scientifically), but SHA-3 is just announced: it will take a few more months before we can get a specification (although we can prepare implementations based on what was submitted for the competition). What must be done now (and should have been done a decade ago, really) is to prepare protocols and applications for algorithm agility, i.e. the ability to switch functions if the need arises (in the same way that SSL/TLS has "cipher suites").

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    It's also worth noting that although NIST thinks SHA-3 is less likely to break in the future than SHA-2 there's no guarantee that they're correct. It's possible (if very unlikely) that someone will publish an attack that makes it no more secure than a CRC hash tomorrow; at which point NIST (with egg on its face) will have resume its preference for SHA-2. – Dan Is Fiddling By Firelight Oct 04 '12 at 19:44
  • 7
    @DanNeely: well, what NIST actually says is that it is unlikely that SHA-2 and SHA-3 will be broken _at the same time_. I don't think they say that SHA-2 will be broken _before_. They officially do not prefer one over the other (both are "Approved algorithms"). – Thomas Pornin Oct 04 '12 at 19:57
  • 1
    @ThomasPornin, Re "*SHA-2 turned out to be more robust than expected*"; What was the expectation? For it to last 3 years? Re "*Let's not be hasty*"; it's been almost half a decade now, do you consider Keccak *stabler* than SHA2? – Pacerier Apr 15 '16 at 09:54
  • Isn't RIPEMD160 and its lengthened variants a suitable "backup" also? Why hasn't NIST really considered that algo for standardisation? Is it purely the fact that it's a shorter hash and they wanted something 256 bit as a base? As far as I know it has also stood the test of time against theoretical attacks like SHA2. – thomasrutter Feb 23 '17 at 01:03
  • 1
    NIST's press release also confirms that they view it as a backup just in case SHA-2 gets compromised. https://www.nist.gov/news-events/news/2015/08/nist-releases-sha-3-cryptographic-hash-standard – Richard Connamacher Feb 23 '17 at 16:22
10

There's at least one usage for which SHA-2 is seemingly better than SHA-3 and that's key stretching.

SHA-3 was designed to be very efficient in hardware but is relatively slow in software. SHA-3 takes about double the time compared to SHA-2 to run in software and about a quarter of the time to run in hardware.

Since SHA-3 takes double the time to run in software, if you want the same password handling time on your server you would need to do half the number of iterations. But attackers can use a hardware implementation for password cracking. Due to this attackers can crack SHA-3 hashed passswords eight times faster than SHA-2 hashed passwords - 2 times faster because we need to halve the number of hash iterations and 4 times faster because of SHA-3 hardware being faster than SHA-2 hardware.

David Wachtfogel
  • 5,512
  • 21
  • 35
  • 10
    SHA-3, like SHA-2, is not intended for use as a password hash function. – Thaeli Oct 05 '12 at 17:21
  • 10
    SHA-1 and SHA-2 are commonly used as the PRF for pbkdf2 which is a password hash function. As people are likely to start using SHA-3 as the PRF for pbkdf2 it's important to note that it's less appropriate for this use than SHA-2. – David Wachtfogel Oct 06 '12 at 19:15
  • 2
    So you can use it when you have a hardware implementation in your server, I suppose. – Paŭlo Ebermann Nov 04 '12 at 10:56
6

On the 2nd of October, 2012, NIST decided what algorithm was going to be used to perform hashing. This was the Keccak algorithm.

The Keccak algorithm is based on the hermetic sponge strategy. It's the new standard algorithm. We use standards to make have better compatibility.

Keccak was designed by Guido Bertoni, Joan Daemen (one of the creators of AES), Michaël Peeters, and Gilles Van Assche. They built it based on their Radiogatùn algorithm.

Does this mean SHA-2 is unsafe? No SHA-2 is still considered safe, we just know that in the future it will not be safe anymore and we need assurance that there will be will be an alternative available. We also do not want to transition from one day to another, so therefore they already standardised a new hashing algorithm, so people can have time to change and so that we know we have a secure algorithm at hand when we need it.

Community
  • 1
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 13
    It's important to note that currently there's no reason to believe SHA-3 (Keccak) is more secure than SHA-2. For all we know, SHA-2 could be more secure than SHA-3. So just as we "know [I would say assume] that in the future [SHA-2] will not be safe anymore" the same is true for SHA-3 and there's no knowing which of the two will be compromised first. – David Wachtfogel Oct 04 '12 at 17:07
3

One benefit I see of SHA-3 over SHA-1 and SHA-2 is that it is not sensitive to extension attacks. That means that protocols based on it (e.g. MACs) are inherently more robust.

SquareRootOfTwentyThree
  • 670
  • 5
  • 12
  • 9
    HMACs (hash-based MACs) as defined by [RFC 2014](http://tools.ietf.org/html/rfc2104) are already protected from extension attacks. The advantage of SHA-3 is that a computationally-simpler `SHA-3(key | data)` can suffice as a MAC. – Stephen Touset Oct 06 '12 at 00:56