SHA-3 was released by NIST just over 4 years ago this week. In my experience it does not seem to be as widely used as I might have expected. I see SHA-2 and even SHA-1 more often. What are your opinions on why this is the case?:
$\begingroup$
$\endgroup$
3
-
$\begingroup$ This question/answer and those directly linked cover #1: crypto.stackexchange.com/questions/15727/… $\endgroup$– Richie FrameAug 10, 2019 at 17:27
-
$\begingroup$ @RichieFrame Perhaps I'm completely missing it, but how does that say anything about security concerns about SHA-3? It seems to be about changing some parameters by NIST, particularly in relation to padding, which supposedly has no adverse affect on security... but it does not mention anything about Bruce Schneier or that there were any security concerns with SHA-3 to begin with. What do you mean exactly? (Note that the content your comment refers to has moved to this answer: crypto.stackexchange.com/a/72527/2512 ) $\endgroup$– LucAug 13, 2019 at 10:59
-
$\begingroup$ @Luc The other question linked in that question listed the "proposed" changes regarding capacity and preimage resistance, as well as the rationale by both NIST and the Keccak team. My answer states that those changes never made it into SHA-3 $\endgroup$– Richie FrameAug 14, 2019 at 23:37
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
9
First, you're taking the question backwards. Inertia is the default position. You shouldn't be looking for reasons not to switch, but for reasons to switch. If there are no strong reasons to switch, nobody will switch.
Security is not a reason. Between SHA-2 and SHA3, there is no reason to believe that one is more secure than the other. It isn't like when switching from MD5 to SHA-1 or from SHA-1 to SHA-2, where in each case the older function has structural weaknesses that did lead to attacks, and had a smaller output size that was starting to raise concerns over brute-force attacks. SHA-2 and SHA3 have the same sizes and no known structual weaknesses.
Performance is not a reason for most applications. Indeed, performance is a reason not to switch. SHA3 is slower than SHA-2 on a general-purpose processor. It was one of the slowest finalists of the SHA3 competition across various processors. This is not a big reason not to switch, because hashes are pretty much never a bottleneck, but it's certainly not an incentive to switch.
SHA3 does have a performance benefit, which is that it's cheap to implement in specialized hardware. It's very fast on a dedicated circuit. This is especially important for low-power devices: SHA3 costs fewer Joules per byte than SHA-2 (or any other SHA3 finalist) when implemented in hardware. So IoT may drive the adoption of SHA3. However, hardware design takes time, and hardware designers are conservative (you can't fix bugs in hardware), so this won't happen any time soon. Furthermore, a hardware implementation of SHA3 uses more gates than SHA-2, so it costs more to build a SHA3 device, even if it costs less to use afterwards, therefore there isn't a clear cost incentive to switch even when a low power requirement is critical.
SHA3 also has a versatility benefit. The same core primitive (the Keccak sponge) can not only be used as a hash, but also as a MAC (KMAC, at lower cost than HMAC), as a key derivation function (SHAKE with a partially-secret input, at a lower cost than constructions such as HKDF), etc. It's not that SHA3 can do things that nobody else can do, but it can do things that otherwise require more complex combinations of primitives. That's an incentive to switch, but only in circumstances where 1. you need those extra things and 2. it is a problem to combine more code. Again, IoT (which wants low-cost, low-power devices) may look towards SHA3, but only once protocols that use more than SHA3's hash functionality are defined and start being deployed.
Coming back to security, a benefit of SHA3 is that it's very different from SHA-2. Indeed this is one of the main reasons it was chosen over other SHA3 proposals: since its construction is different, if a new class of attacks breaks SHA-2, it's unlikely to apply to SHA3, and vice versa. The security benefit would not be in switching to SHA3, but in deploying software and protocols that support both, so that if a weakness is found in SHA-2, the world can quickly and cheaply transition to SHA3.
answered Aug 10, 2019 at 14:42
Gilles 'SO- stop being evil'Gilles 'SO- stop being evil'
17.9k4 gold badges45 silver badges88 bronze badges
-
7$\begingroup$ a bit of trivia from the hardware side, I've yet to see anyone ask for SHA-3. There's a lot of BLAKE2 implementations, which I will guess is driven by silicon space alone. $\endgroup$– b degnanAug 10, 2019 at 21:43
-
24$\begingroup$ You consistently write SHA3 without a dash where for SHA-1 and SHA-2 you always use the dash. The NIST spec also writes it as SHA-3 but knowing you as rather precise I assume it is not a typo when you write SHA3. Care to enlighten me if there is a difference between SHA3 and SHA-3? $\endgroup$– reneAug 11, 2019 at 12:43
-
2$\begingroup$ @FutureSecurity The question was about SHA-2 vs SHA-3 (which is Keccak). I would not recommend using other SHA-3 finalists because they're unlikely to get as much cryptanalysis going forward. $\endgroup$ Aug 11, 2019 at 20:58
-
10$\begingroup$ @rene The official name of the family is indeed SHA-3, but the name of individual algorithms is SHA3-224 etc. I should have used SHA-3, but given that to use one of the SHA-3 algorithms, you need to write “SHA3-…”, I expect the SHA3 spelling to be even more prevalent than SHA1 and SHA2. $\endgroup$ Aug 11, 2019 at 21:01
-
2$\begingroup$ @Luc Die area. The smallest implementations of BLAKE2 are smaller than Keccak. See e.g. pdfs.semanticscholar.org/649a/… table 4. $\endgroup$ Aug 13, 2019 at 11:20
$\begingroup$
$\endgroup$
5
Since this question is asking about opinions, it's hard to give the correct answer (alternatively, all possible answers are correct, because they're an opinion). However, my opinion:
I believe that there are several aspects contributing to it:
Most application designers (that is, the people who use crypto to actually solve a problem) generally don't actually specify something as low level as the hash function; instead, they specify things at a higher level (e.g. perhaps the public key signature method, or the encryption protocol), and use whatever hashes those higher level primitives use.
As for designers of the lower level primitives, they tend to update things at a much slower rate - and hence, they tend to take a while to pick up things like SHA-3 (especially if there isn't a strong perceived need to make the change).
As for perceived need, SHA-2 is mostly seen as perfectly adequate technology, which solves the problems we give it, and at generally reasonable cost, and so there is no immediate need to spend effort at moving to SHA-3. The big advantage to SHA-3 is that it can be implemented faster, and for most applications, the speed of the hash function just isn't a major factor.
Now, we will likely see more adoption over the next several years; if you go through the NIST postquantum candidates, they tend to use SHAKE (at least, the ones that need a hash function). That means that, as they are taken up by the applications (and used in real products), they'll take SHA-3 with them (and one would expect that, given that there is now a SHA-3 implementation in the crypto library already) it'll find more general use.
However, as for becoming 'the standard' (that is, people are actually discouraged from using SHA-2) I don't see that for a very long time (barring a cryptanalytic discovery); as far as we can tell, it doesn't have any weakness, and it does have some practical advantages over SHA-3 (at least, I believe it's easier to build with a minimal number of gates)
-
$\begingroup$ “SHA-3 is that it can be implemented faster” actually mostly no, SHA3 is consistently faster in hardware and slower in software; it's only faster in a dedicated circuit. $\endgroup$ Aug 10, 2019 at 14:43
-
$\begingroup$ As someone who helps maintain a few security libraries, I would prefer SHA-256 over SHA-3 because there's more hardware support. SHA-256 acceleration is available on x86 (Goldmont), Aarch64 (Armv8.1-a), PowerPC (Power8) and MIPS. SHA-3 acceleration is only available on Aarch64 (Armv8.4-a), as far as I know. SHA-3 is also slower in software when hardware acceleration is not available. $\endgroup$– user10496Aug 13, 2019 at 5:15
-
$\begingroup$ ... there's SHA-3 acceleration for aarch64? I had never heard from commodity hardware with an actual Keccak implementation! $\endgroup$ Aug 14, 2019 at 12:12
-
$\begingroup$ @jww Does it implement SHA-3 itself, or the Keccak-f permutation function? $\endgroup$– forest ♦Aug 21, 2019 at 21:34
-
$\begingroup$ @forest - I believe it is SHA3 specifically since there is also SM3, SM4 and SHA512. But I could be wrong. I don't know anyone who has implemented it (yet). I just checked OpenSSL and Andy has not cut it in yet. I noticed Jack Lloyd merged a PR for ARMv8.4's SM4 at Add support for ARMv8 SM4 instructions. As soon as I can buy hardware with the ISA, then I will cut it in. I require testing on real hardware for an algorithm. $\endgroup$– user10496Aug 22, 2019 at 3:20
$\begingroup$
$\endgroup$
2
Mostly option 2. People are lazy. Furthermore, those using SHA-2 have no good reason to switch. Those using SHA-1 are lazy, and have been lazy for a while. Another reason is compatibility, If I use SHA3 in my certificate some software may not be able to use it, and if SHA2 is fast and as secure for all practical purposes why should I opt for the less compatible option. I don't think there are serious security concerns against SHA-3, some think it wasn't the best candidate (I'm one of them) but that doesn't mean they think objectively it is an insecure hash function. Most developers do not make an informed choice about cryptographic primitives and inertia is a good choice. I think very few are holding out for more cryptanalysis.
-
3$\begingroup$ My favorite SHA-1 fact is that the algorithm was broken in 2005. The collision published a couple years ago required about as much computing time as estimated for the 2005 break. Like with Heartbleed and Dual EC DRBG, it was a "don't say we didn't warn you" event. Except developers point at those three things and say "Why should we listen to you now when you didn't warn us about these things?" $\endgroup$ Aug 11, 2019 at 15:41
-
$\begingroup$ SHA-2 isn't so bad though. If it weren't for length extension problems the best argument for upgrading to something else would just be for performance reasons. SHA-2's use today isn't as facepalm worthy as SHA-1 or RC4 use was years ago. $\endgroup$ Aug 11, 2019 at 15:49
$\begingroup$
$\endgroup$
3
Below are some suggestions I originally included in the question but fit better as an answer.
1) There are still some concerns about SHA-3. I recall that there was some controversy when released, e.g. Bruce Schneier and others raised some concerns. Are these concerns still lingering? [Based on other answers I now see that this is not really valid. I also researched Bruce Schneider’s criticism further and it was in relation to NIST-enforced changes to the capacity optionality to balance security and performance, not security as such]
2) People are just slow/lazy when it comes to adopting new standards and four years is not a long time. Adoption will continue to grow slowly until SHA-2 is shown as weak or withdrawn by NIST.
3) Many developers wait to see a crypto function in use for 5 years and widely research and attacked before they adopt (ie more conscious/systematic approach than 2). SHA-3 usage will likely increase significantly in the next couple of years and become the standard.
-
$\begingroup$ The controversy was entirely political because the finalization was concurrent with an onslaught of Snowden disclosures including Project BULLRUN. There is no technical foundation to the controversy—the result is that the fixed-size hash functions SHA3-256 etc. are slower than they need to be for their security goals, because of bad timing with Snowden. Fortunately SHAKE128 avoids this mistake. $\endgroup$ Aug 21, 2019 at 16:47
-
$\begingroup$ @SqueamishOssifrage The controversy was about the capacity (and thus collision resistance), right? Not about the number of rounds or anything else that would improve resistance against cryptanalysis? $\endgroup$– forest ♦Aug 21, 2019 at 21:31
-
$\begingroup$ @forest It was about the capacity, yes. Specifically, the capacity for (e.g.) SHA3-256, namely $c = 512$, is twice what it needs to be, namely $c = 256$, for a 128-bit security level, at substantial cost to performance and no meaningful improvement in security. $\endgroup$ Aug 21, 2019 at 22:06