12

This question is a duplicate, however I feel that it's necessary given the question. The original was posted in 2012: about 5 years ago before NIST had even published the final specification.

The question is more or less the same as the original. Has SHA3 been studied enough to be considered secure for high-value situations, and is there an advantage to using it over it's predecessor, SHA2. Basically, should we use it?

forest
  • 64,616
  • 20
  • 206
  • 257
Awn
  • 480
  • 4
  • 15
  • Since this is a standard you are effectively asking if NIST would declare it as a standard even if it was not studied enough. That's usually not how it works. – Steffen Ullrich Feb 25 '17 at 19:07
  • @SteffenUllrich I agree with what you're saying, and so I think the latter part of the question is more helpful: is there an advantage to using it over it's predecessor. – Awn Feb 25 '17 at 19:09
  • I've read (somewhere, don't remember) that SHA3 had proved to be terrible at hashing passwords. I don't know if this is true. There are better ways to hash passwords than using a general-purpose hash function, but as PBKDF2 is still used and recommended it's worth noting. – Hey Feb 25 '17 at 19:11
  • 1
    @YdobEmos well yes, it's not a KDF, it's a normal hashing function. – Awn Feb 25 '17 at 19:13
  • 1
    @YdobEmos: *somewhere* is not really a reputable source of information. – Steffen Ullrich Feb 25 '17 at 19:13
  • @Eclipse but SHA2 is commonly used to hash passwords, with multiple itérations and a salt, even if it's not optimal. That's why I pointed it out. – Hey Feb 25 '17 at 19:15
  • 1
    @YdobEmos: I think what you have read *somewhere* is either nonsense or it was actually written something else. The main reasons a hash is used in KDF is because you cannot reverse it and because output is uniform. SHA-3 would be a very bad hash function if it would be worse in any of these than SHA-2. – Steffen Ullrich Feb 25 '17 at 19:17
  • @SteffenUllrich it was in the comments of a Schneier on Security article. Again, the comments are usually anonymous so other sources are needed, but the discussion under this article can be interesting (Ctrl+F "password") : https://www.schneier.com/blog/archives/2012/10/keccak_is_sha-3.html . Some seem to be worried about resistance to bruteforce attacks, and the fact that the inferior software implementation performance can give too much of an advantage to attackers who use specialized hardware against users who use a software implementation. – Hey Feb 25 '17 at 19:20
  • @YdobEmos: I see now what they were talking about: the reason is actually that SHA-3 can be faster than SHA-2 because it can be effectively implemented in hardware. So you would need more rounds to make it slow enough again. – Steffen Ullrich Feb 25 '17 at 19:23
  • SHA-2 has a number of weaknesses, not the least of which is that there are currently high-powered ASICs that are dedicated to breaking it. https://online.tugraz.at/tug_online/voe_main2.getvolltext?pCurrPk=69018 I would use SHA-3 for any new applications where compatibility is not a major concern. – Erik Aronesty Jul 19 '18 at 15:12

3 Answers3

7

I'm not convinced that we should. SHA-3 has some nice features for sure, but for the reasons I list below, I would probably suggest using SHA-2 or BLAKE2 for the time being. Even NIST themselves say:

Currently there is no need to transition applications from SHA-2 to SHA-3.

That said, you may still be thinking "why not"?

  1. SHA-3 is not yet FIPS-140 compliant. Without FIPS 140-3, it is out of reach of non-military government agencies and government contractors. If you are worried about FIPS compliance, you are stuck with the SHA-2 suite for now. SHA-3 was included in FIPS 140-2 Annex A, and even though this document still says "Draft" on the cover page it appears to have been finalized via these two pages.
  2. Performance. SHA-3 is incredibly fast in hardware (ASIC) implementations. However, it is much slower in software running on CPUs with limited registers, meaning it's less useful generally*. Its primary competitor (at least, in the aftermath of the competition) is BLAKE2, which has shown to be much faster on general CPUs and is sometimes favored over Keccak/SHA-3 for other reasons. While I feel that NIST understated the in-software performance differences between finalists, their comments on performance in the last round of decision making may be helpful to provide context. From NISTIR 7896, section 3.2:

    a. All five finalists perform well enough to be usable in most applications.
    b. None of the five finalists is the best for every application, and none offers really compelling improvements over the SHA-2 algorithms.
    c. The ARX-based algorithms, BLAKE and Skein, perform extremely well in software.
    d. Keccak has a clear advantage in throughput/area performance in hardware implementations.
    e. Grøstl and JH are considerably slower than the other three algorithms in most software implementations.

  3. Potentially unnecessary prudence. It is also worth noting that BLAKE got negative remarks due to how similar it was to SHA-2. Out of prudence, this helped Keccak/SHA-3 win the competition. From NISTIR 7896, section 3.4:

    b. Because SHA-2 is an ARX-based design with a key schedule, it has some important design elements in common with BLAKE and Skein, although neither is closely related to SHA-2. However, cryptanalytic tools that apply to SHA-2 in the future seem more likely to apply to BLAKE or Skein than to the other three finalists.

* Recall that we're discussing cryptographic hash functions here, not necessarily password hashing functions or KDFs.

Some more reading that may be worth the time:

  1. NIST may not have you in mind, by Adam Langley
  2. The Keccak sponge function family
  3. NISTIR 7896
  4. BLAKE2: “Harder, Better, Faster, Stronger” Than MD5
  5. Why Replace SHA-1 with BLAKE2?
  6. Maybe Skip SHA-3
Luc
  • 31,973
  • 8
  • 71
  • 135
JZeolla
  • 2,936
  • 1
  • 18
  • 25
  • "None of the five finalists is the best for every application, *and none offers really compelling improvements over the SHA-2 algorithms*." I think that latter phrase there says a lot. With no clear sign out there that the SHA-2 family is in danger of having imminent cryptographic breakthroughs made against it (to the imperfect extent we can predict such things, of course), then the lack of a broad improvement in performance leaves SHA-3 sort-of hanging out there with a main purpose of being a backup/contingency option in case the unexpected happens.(Which isn't bad to have, of course.) – mostlyinformed Mar 06 '17 at 05:10
  • 1
    SHA-3 has actually been listed in FIPS 140-2 Annex A since 2015. – Luis Casillas Jan 10 '18 at 00:33
  • It appears you are right, thanks @LuisCasillas. That said, did Annex A ever officially come out of draft? I updated the post above to add some relevant information. – JZeolla Jan 10 '18 at 04:21
  • You say the prudence is unnecessary, but do not elaborate on why that would be unnecessary. I think it's a good thing to have a hash function that is dissimilar to the existing de facto standard, leaving performance in software as the only reason. And the two other non-ARX-based finalists (JH and Grøstl) are said to be even slower in software than Keccak already is. – Luc Jan 10 '18 at 08:19
  • SHA-3 has one other advantage. Because it can keccak can work with arbitrary bit sizes, it can scale as needs change by simply changing a flag for the forseeable future. So the work integrating it could be rewarded with a very long term solution. – Erik Aronesty Jul 19 '18 at 15:05
-2

You should be using the strongest cipher you can, and SHA3 seems to be suitable. Altough, you are ahead of your age, since almost nobody uses it. Not even OpenSSL supports SHA3. The thing is, SHA2 is still generally considered secure, and for a complex system, you would be better off choosing SHA2 over SHA3 to avoid incompatibility issues.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
Rápli András
  • 2,124
  • 11
  • 24
  • 3
    SHA-3 is not a priori a stronger hash than SHA-2. Its selection serves more as backup in case ARX-based designs are found to have common weaknesses, breaking SHA-2 and related hashes. SHA-2 has the benefit of surviving nearly two decades' worth of cryptanalysis that SHA-3 has yet to be subject to. – Stephen Touset Mar 07 '17 at 01:55
-5

Look at this chart: http://valerieaurora.org/hash.html

What do you think you should be using?

As a general rule, you should use the strongest hashing method available to you at the time (in this case SHA-3), unless you have a compelling reason not to, such as:

  • Compatibility

  • Performance

  • Regulatory requirements (e.g. Must be using FIPS validated crypto implementation)

So, if you can't use SHA-3, next best would be SHA-2.

myron-semack
  • 488
  • 4
  • 8