[ajsfoux234]

The vulnerability impacts 'the "official" SHA-3 implementation'. How widely used is it for SHA-3 hashing compared to something like OpenSSL?

[duskwuff]

SHA-3 is rarely used in general. Most applications still use SHA-2 hashes (such as SHA256).

[PeterisP]

An obvious issue is that many protocols do two-sided negotiations of crypto algorithms during a handshake - so one of "most applications" which uses SHA-2 hashes by default could be vulnerable to a network connection saying "I don't support SHA-2, let's use SHA-3 pls?" and then exploiting the buffer overflow.

In a similar manner, apps that verify signatures/certificates often let the certificate specify which algorithm is used, so again effectively an attacker may be able to force the app to use SHA3 as long as it uses a library that has some support for it.

[tinglymintyfrsh]

Rare != bad && rare != unimportant.

The point of NIST standardizing on SHA-3 is to gradually replace SHA-2 due to the rise of computing power and the likelihood it will become as weak as SHA-1 is now in the near future. Unfortunately, like American credit cards vs. European chip & pin, it's going to take forever to adopt.

[baby]

I've mostly seen SHA-3 used in more modern applications, it's used a lot in cryptocurrencies (with BLAKE2)

[halostatue]

I’d love to use SHA-3, but I’m waiting until I see SHA-3 in standard libraries for my most-used languages.

[derefr]

The version in the Golang stdlib defaults to a pure-go implementation... unless you're compiling for amd64, in which case you get an assembler variant apparently directly derived from the XKCP package (https://github.com/golang/crypto/blob/master/sha3/keccakf_am...).

Slightly concerning news for the (mostly-Golang-based) Ethereum ecosystem, which relies on SHA3-256 for pretty much everything...

[tptacek]

Easy enough to test, right?

    func main() { 
      h := sha3.New224()
      buf := make([]byte, 4294967295)
      h.Write(buf)
      sum := h.Sum(nil)
      fmt.Printf("%x\n", sum)
    }

Doesn't crash on my amd64 dev machine.

Later

I could have just looked at the code, too: the assembly you've linked to is just the Keccak permutation, not the entire Go hash; the buffer management is done in Go, not in assembly.

[bugfix-66]

I read the code carefully, both yesterday and today, and it's correct.

Read it yourself here:

https://cs.opensource.google/go/x/crypto/+/refs/tags/v0.1.0:...

There's obviously no problem.

[bugfix-66]

All the Go code is safe. No bugs.