5 ms·

Nope. SHA-2 (known to developers as SHA224, SHA256, SHA384, and SHA512) was the replacement for SHA-1. SHA-3 was created as an insurance policy in case the SHA-

Nope. SHA-2 (known to developers as SHA224, SHA256, SHA384, and SHA512) was the replacement for SHA-1. SHA-3 was created as an insurance policy in case the SHA-2 family was broken too. So far, it hasn't been. We won't need a SHA-4 any time soon. SHA-2 is fine, BLAKE2 is fine (and faster), SHA-3 is fine.

asdfv09s9d80fu9 7y ago
Nice try, NSA!
optimiz3 7y ago
Also, SHA-2 underpins Bitcoin; it's the ultimate billion dollar pot of gold. SHA-2 is perhaps the most exhaustively researched (both publicly and privately) cryptographic hash because of this.
- JeremyBanks 7y ago
  deleted
  - RL_Quine 7y ago
    SHA2 is used in many places in bitcoin. It’s collision resistance is used too, ie in merkel trees.
- mehrdadn 7y ago
  Do you know why it's said to be last-resort in the article?
  - CiPHPerCoder 7y ago
    Catalin was quoting me in the article, so it's only fair that I elaborate here. There are four common flavors of the SHA2 family you're likely to run into: - SHA-224 - SHA-256 - SHA-384 - SHA-512 And then there are two more variants of "truncated SHA-512" (except they also use different initialization vectors than SHA-512, which is kind of an important detail) - SHA-512/256 - SHA-512/224 These latter two don't have nearly the cross-platform support as the first four. For example, in PHP, hash('sha256', 'some text') worked since PHP 5.1.2 (without PECL), but hash('sha512/256', 'some text') didn't work until PHP 7.1.0 (which is only a few years old). See for yourself: https://3v4l.org/A1dZc https://3v4l.org/A1dZc As a typical software developer, you might see SHA-{magic/numbers} and probably discover from Google/StackOverflow/etc. that they're in the SHA2 family and that the SHA2 family is secure, and then reason that whatever you're doing must also be also secure. But there's a problem. SHA-256 and SHA-512 (not the truncated varieties) are known to be vulnerable to length extension attacks. This is only a problem if you're using these hash functions in a vulnerable way. (Which isn't as uncommon as you'd think in homebrew crypto.) If you're using HMAC, length extension attacks are a moot point. There's a reason 'tptacek always recommends HMAC for symmetric authentication. SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not vulnerable to length extension attacks. BLAKE2 is not vulnerable to length-extension attacks. It's also at least as secure as SHA2, but faster than MD5. SHA3 is at least as secure as BLAKE2, but is significantly slower in software. Thus, the recommendations are: - BLAKE2 for speed and security - SHA-512/256 if you want speed, length-extension attack resistance, and arbitrary standards compliance - SHA3-256 if you care more about security and what the FIPS authors think than speed - SHA-384 if you're concerned about backwards compatibility but don't want to accidentally cause junior developers that poorly mimic your designs to introduce LEAs into their code - Any other SHA-2 family hash function if you're not interested in all of this nuance and want something guaranteed to be secure for the next few years that is widely implemented Of course, there should be a huge asterisk with this list: If you're not a crypto expert, you shouldn't be making this decision. Just stop using SHA1. It's also worth noting that Marc Stevens-- hash function breaker extraordinaire-- disagrees with my recommendation because BLAKE2 isn't a {NIST,FIPS,ISO,whateverStandardsBodyYouTrust}-approved hash function, and for better or worse, believes strongly in reinforcing public trust in standards organizations. https://twitter.com/realhashbreaker/status/1128381600146894848 https://twitter.com/realhashbreaker/status/11283816001468948... He has a point in general, but in this specific case, I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. Also, standards bodies have a nasty habit of digging in their heels on their mistakes, instead of issuing new guidance in response to research. See also: WPA3 and Dragonfly vs SPAKE2-EE or OPAQUE. For a higher-level example, look at the failures baked into the JOSE standards (JWT, etc.) versus PASETO. Fun fact: If you take JOSE and replace JSON with CBOR, without fixing any of the protocol security problems, you get COSE... which reared its ugly head in W3C's WebAuthn standard. Bad standards never die. Until we get a standards committee that isn't garbage, I don't entirely agree with Marc's appeal to faith here. While NIST et al. certainly do a better job at deciding on primitives than self-styled post-2010 cypherpunks (y'know, the ones that try to cascade a bunch of ciphers together in case one is broken but then use CRC32 for mixing files into the encryption key?), their failure to correct (let alone learn from) their mistakes and update recommendations in a timely manner is a problem that can't be dealt with through blind adherence to whatever they publish.
    - mehrdadn 7y ago
      Ahh so it's because of length extension attacks. Thanks!
    - devit 7y ago
      What do you mean by "at least as secure"? They are different algorithms, so I don't see how their security can be provably related.
      - CiPHPerCoder 7y ago
        Saying "BLAKE2 is at least as secure as SHA-256" is saying that: 1. The best known attacks against SHA-256 have a cost of 2^i for some value of i. 2. The best known attacks against BLAKE2 have a cost of 2^j for some value of j. 3. j >= i
    - avar 7y ago
      > I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. I think you mean "de facto", unless you think NIST is going to amend SHA-3 at this point to designate BLAKE over Keccak. As someone on the sidelines, having read the linked Twitter discussion you had with Marc Stevens your summary of it honestly seems a bit disingenuous. You mention speed prominently, but fail to mention his counterargument that raw hash speed isn't relevant for most applications. In practice hashing speed is drowned out by other things, you're not going to have "Android/iOS devices" (as you bring up) hashing GBs of data as a common use-case, and even if you did the cycles/byte for the hash are nothing compared to other things. For applications where hashing speed does matter (e.g. some server needing to batch-hash things) you have the option of buying hardware-accelerated SHA-256 to get on the order of 30% faster than BLAKE: https://bench.cr.yp.to/results-hash.html https://bench.cr.yp.to/results-hash.html Then as you note downthread your criteria of "at least as secure" only takes into account "known attacks". The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up. Or, in other words, if the algorithm that became SHA-1 hadn't been picked by NIST in 1995 it would be a viable 160-bit hash function today, since there would likely be no known attacks against it, as it would have been obscure enough that nobody would have bothered with it. So the criteria for a "secure" hash must consider some balance of its algorithm, as well as (or more importantly) the cumulative amount of attention cryptographers have spent on it.
  - johncolanduoni 7y ago
    SHA-512/256 is the second resort, and it’s the 512 bit variant of SHA-2 truncated to 256 bits (SHA-384 is similar). Generally any SHA followed by a relatively large number is actually a variant of SHA-2.
aeneasmackenzie 7y ago
Is there any reason not to just use SHA-3? It sounds like it's a real swiss army knife to hear the authors talk about it.
- wongarsu 7y ago
  Right now it has worse library support, worse hardware support, and isn't analysed as thouroughly as SHA512/SHA256. Also SHA-3 seems to be fighting with Blake2 for popularity, it's not immediatly clear to me that SHA-3 will be popular in 10 years (a point for usage in API design etc). But those are temporary problems that might not even matter to you.
- CiPHPerCoder 7y ago
  There are reasons to prefer other functions, but none of those are disqualifying marks on SHA-3. If you have SHA-3 available, just use it. Everything listed in that article is secure today and will probably be secure 10 years from now.

asdfv09s9d80fu9 7y ago

Nice try, NSA!

optimiz3 7y ago

Also, SHA-2 underpins Bitcoin; it's the ultimate billion dollar pot of gold. SHA-2 is perhaps the most exhaustively researched (both publicly and privately) cryptographic hash because of this.

JeremyBanks 7y ago
deleted
- RL_Quine 7y ago
  SHA2 is used in many places in bitcoin. It’s collision resistance is used too, ie in merkel trees.
mehrdadn 7y ago
Do you know why it's said to be last-resort in the article?
- CiPHPerCoder 7y ago
  Catalin was quoting me in the article, so it's only fair that I elaborate here. There are four common flavors of the SHA2 family you're likely to run into: - SHA-224 - SHA-256 - SHA-384 - SHA-512 And then there are two more variants of "truncated SHA-512" (except they also use different initialization vectors than SHA-512, which is kind of an important detail) - SHA-512/256 - SHA-512/224 These latter two don't have nearly the cross-platform support as the first four. For example, in PHP, hash('sha256', 'some text') worked since PHP 5.1.2 (without PECL), but hash('sha512/256', 'some text') didn't work until PHP 7.1.0 (which is only a few years old). See for yourself: https://3v4l.org/A1dZc https://3v4l.org/A1dZc As a typical software developer, you might see SHA-{magic/numbers} and probably discover from Google/StackOverflow/etc. that they're in the SHA2 family and that the SHA2 family is secure, and then reason that whatever you're doing must also be also secure. But there's a problem. SHA-256 and SHA-512 (not the truncated varieties) are known to be vulnerable to length extension attacks. This is only a problem if you're using these hash functions in a vulnerable way. (Which isn't as uncommon as you'd think in homebrew crypto.) If you're using HMAC, length extension attacks are a moot point. There's a reason 'tptacek always recommends HMAC for symmetric authentication. SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not vulnerable to length extension attacks. BLAKE2 is not vulnerable to length-extension attacks. It's also at least as secure as SHA2, but faster than MD5. SHA3 is at least as secure as BLAKE2, but is significantly slower in software. Thus, the recommendations are: - BLAKE2 for speed and security - SHA-512/256 if you want speed, length-extension attack resistance, and arbitrary standards compliance - SHA3-256 if you care more about security and what the FIPS authors think than speed - SHA-384 if you're concerned about backwards compatibility but don't want to accidentally cause junior developers that poorly mimic your designs to introduce LEAs into their code - Any other SHA-2 family hash function if you're not interested in all of this nuance and want something guaranteed to be secure for the next few years that is widely implemented Of course, there should be a huge asterisk with this list: If you're not a crypto expert, you shouldn't be making this decision. Just stop using SHA1. It's also worth noting that Marc Stevens-- hash function breaker extraordinaire-- disagrees with my recommendation because BLAKE2 isn't a {NIST,FIPS,ISO,whateverStandardsBodyYouTrust}-approved hash function, and for better or worse, believes strongly in reinforcing public trust in standards organizations. https://twitter.com/realhashbreaker/status/1128381600146894848 https://twitter.com/realhashbreaker/status/11283816001468948... He has a point in general, but in this specific case, I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. Also, standards bodies have a nasty habit of digging in their heels on their mistakes, instead of issuing new guidance in response to research. See also: WPA3 and Dragonfly vs SPAKE2-EE or OPAQUE. For a higher-level example, look at the failures baked into the JOSE standards (JWT, etc.) versus PASETO. Fun fact: If you take JOSE and replace JSON with CBOR, without fixing any of the protocol security problems, you get COSE... which reared its ugly head in W3C's WebAuthn standard. Bad standards never die. Until we get a standards committee that isn't garbage, I don't entirely agree with Marc's appeal to faith here. While NIST et al. certainly do a better job at deciding on primitives than self-styled post-2010 cypherpunks (y'know, the ones that try to cascade a bunch of ciphers together in case one is broken but then use CRC32 for mixing files into the encryption key?), their failure to correct (let alone learn from) their mistakes and update recommendations in a timely manner is a problem that can't be dealt with through blind adherence to whatever they publish.
  - mehrdadn 7y ago
    Ahh so it's because of length extension attacks. Thanks!
  - devit 7y ago
    What do you mean by "at least as secure"? They are different algorithms, so I don't see how their security can be provably related.
    - CiPHPerCoder 7y ago
      Saying "BLAKE2 is at least as secure as SHA-256" is saying that: 1. The best known attacks against SHA-256 have a cost of 2^i for some value of i. 2. The best known attacks against BLAKE2 have a cost of 2^j for some value of j. 3. j >= i
  - avar 7y ago
    > I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. I think you mean "de facto", unless you think NIST is going to amend SHA-3 at this point to designate BLAKE over Keccak. As someone on the sidelines, having read the linked Twitter discussion you had with Marc Stevens your summary of it honestly seems a bit disingenuous. You mention speed prominently, but fail to mention his counterargument that raw hash speed isn't relevant for most applications. In practice hashing speed is drowned out by other things, you're not going to have "Android/iOS devices" (as you bring up) hashing GBs of data as a common use-case, and even if you did the cycles/byte for the hash are nothing compared to other things. For applications where hashing speed does matter (e.g. some server needing to batch-hash things) you have the option of buying hardware-accelerated SHA-256 to get on the order of 30% faster than BLAKE: https://bench.cr.yp.to/results-hash.html https://bench.cr.yp.to/results-hash.html Then as you note downthread your criteria of "at least as secure" only takes into account "known attacks". The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up. Or, in other words, if the algorithm that became SHA-1 hadn't been picked by NIST in 1995 it would be a viable 160-bit hash function today, since there would likely be no known attacks against it, as it would have been obscure enough that nobody would have bothered with it. So the criteria for a "secure" hash must consider some balance of its algorithm, as well as (or more importantly) the cumulative amount of attention cryptographers have spent on it.
- johncolanduoni 7y ago
  SHA-512/256 is the second resort, and it’s the 512 bit variant of SHA-2 truncated to 256 bits (SHA-384 is similar). Generally any SHA followed by a relatively large number is actually a variant of SHA-2.

aeneasmackenzie 7y ago

Is there any reason not to just use SHA-3? It sounds like it's a real swiss army knife to hear the authors talk about it.

wongarsu 7y ago
Right now it has worse library support, worse hardware support, and isn't analysed as thouroughly as SHA512/SHA256. Also SHA-3 seems to be fighting with Blake2 for popularity, it's not immediatly clear to me that SHA-3 will be popular in 10 years (a point for usage in API design etc). But those are temporary problems that might not even matter to you.
CiPHPerCoder 7y ago
There are reasons to prefer other functions, but none of those are disqualifying marks on SHA-3. If you have SHA-3 available, just use it. Everything listed in that article is secure today and will probably be secure 10 years from now.