# Why is SHA3 more secure than SHA2?

Why are SHA3 algorithms considered more secure than their SHA2 counterparts? Surely in part, it is due to their resistance to length extension attacks. But specifically, when considering collision resistance they have the same O(n) attack times.

Is it because they are more resistant to preimage attacks?

• "Why are SHA3 algorithms considered more secure than their SHA2 counterparts?" - I personally suspect a large part of the reason many assume that is because $3 > 2$... Sep 24, 2021 at 18:49
• There is no cryptographic hash function that has broken pre-image resistance, even MD5 the existing pre-image attack is not practical than the brute force. Sep 24, 2021 at 21:02
• "Why are SHA3 algorithms considered more secure than their SHA2 counterparts?" This is not Wikipedia, but this just begs for a [citation-needed]. Sep 25, 2021 at 0:00
• @poncho Reminds me of how in non-Russian speaking countries the sale numbers of export modification of KAMAZ trucks were consistently below the modification for the internal market, because the latter featuread a Russian version of the logo, КАМАЗ, and people assumed that KAMA3 is better than KAMA2. Sep 25, 2021 at 19:40

TL;DR: the assertion "SHA3 is more secure than SHA2" is unproven when we consider collision resistance, or preimage resistance.

Addition: there are reasons to prefer SHA3, including being a more general tool since it's a plausible instantiation of a random oracle (contrary to SHA2 due to the length extension property). I refer to this answer for more.

We don't know which of SHA2 or SHA3 is more collision-resistant. Both try to achieve the best possible collision resistance for a $$n$$-bit hash, e.g. cost of $$2^{n/2}$$ hashes (within a factor not too far from 1) to achieve collision with probability ≈39% of success.

We don't know which of SHA2 or SHA3 is more preimage-resistant. Both try to achieve the best possible preimage resistance for a $$n$$-bit hash, e.g. cost of $$2^n$$ hashes (within a factor not too far from 1) to achieve preimage with probability ≈63% of success. That was not always the case: briefly, the preimage resistance of draft SHA3 was lowered, in the interest of making it faster, way below that (conjectured) for SHA2. But that change caused controversy and was reversed, see this. Now we have to use SHAKE when we don't want the arguably overkill preimage-resistance of SHA2, and prefer more speed instead.

Argument that we don't know: if we knew which or SHA2 or SHA3 is the most secure from the standpoint of collision or preimage resistance (by a factor larger than the speed difference, which makes the faster algorithm correspondingly less secure), one of SHA2 or SHA3 would be broken from that standpoint.

• Exactly: we don't know. The history of cryptography is largely a story of people saying that something was certain--until it wasn't. Sep 25, 2021 at 9:19
• "But that change caused controversy and was reversed" What's sad about this decision is that increasing the number of rounds of SHAKE-256 to match the performance of SHA3-512 would have resulted in a function I'd trust much more than the SHA3-512. Sep 25, 2021 at 10:36
• @Patriot only the Sith deal in absolutes Sep 27, 2021 at 4:58

This is more of an addendum to fgrieu's answer than an answer in itself, but 3 things stand out that COULD make SHA3 more secure than SHA2 from a design standpoint.

The first and most obvious is the state size, SHA3 is substantially larger at 1600 bits than even SHA512... at only 512 bits. SHA3 being a sponge function gets its security level from how much of that state size it keeps hidden from the final hash output, and that is one of the reasons it is immune to length extension attacks. SHA-512 and SHA-256 output their entire state, the rest of the SHA2 family truncates to the desired length. Having the entire state available can make certain attacks against block cipher based hashes like SHA2 easier, tough truncation may lead to other attacks.

The second may change over time, the security buffer, or how much of the full round count is not broken by the best attacks against the hash function. For collisions against SHA2 this is between 56% (practical collisions for SHA-256) and 30% (pseudocollision for SHA-256) but a whopping 79% for SHA3 (practical 5 rounds collision)

And the final thing is more about the way the hash can be implemented in software, SHA3 on 64-bit platforms requires less code to implement, which means less code to possibly be implemented insecurely. It is also considered (by most people that I know) easier to read the SHA3 code, and the round constants can be generated algorithmically at runtime.

Why are SHA3 algorithms considered more secure than their SHA2 counterparts

The SHA3 competition was created because of new attacks against MD5 and SHA-1, which created a perceived threat that future analysis of SHA2 that could lead to practical attacks. This has not come to pass, and SHA2 has stood its ground against cryptanalysis.

The SHA3 competition spawned many fantastic hash functions that were more functionally capable than SHA2, had better hardware performance, or had better performance to security ratios. But that does not mean that SHA3 is the de facto MORE secure hash function.. but it also does not mean that SHA2 is either. They are very different designs, and SHA3 is more capable, AND SHA3 has a potentially higher security buffer, but neither are broken (except for length extension attacks, but that was already known).

I know you already mentioned length extension attacks in your question, but I don't think the importance of that can be overstated in how SHA3 is practically more secure than SHA2 - especially whenever you'll be designing your own cryptographic protocols/systems on top of it. Thanks to length extension attacks, use of SHA2 may require active measures (e.g. HMAC) beyond the hash itself in order to use it safely, and most people using it don't understand this. Even if they do, the need occupies space in one's mental model that could be spent on more valuable things.

In addition, implementations of SHA2 may be subject to side channels that, in certain contexts, leak information about the data being hashed. This can be critical when the hash is used with key material, such as in HMAC or signatures. This paper claims to successfully recover private keys from the (2017) WolfSSL implementation of Ed25519 using such a side channel. SHA3 by design does not invite side channel leaks.