SHA-3 Buffer Overflow • Hacker News Board

Re: SHA-3 Buffer Overflow

#71

Post by dlubarov » Fri, Oct 21, 2022, 12:31 AM UTC

tptacek wrote: post #64

tinglymintyfrsh wrote: post #51

Earlier quoted context omitted.

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.

No. The "rise in computing power" doesn't jeopardize SHA2. There are important design differences between SHA1 and SHA2 (here's where in my younger days I'd pretend that I could rattle off the implications of nonlinear message expansion off the top of my head). SHA2 is secure; don't take my word for it through, you can find one of the Blake2 designers saying SHA2 is unlikely ever to be broken, or Marc Stevens on a Tw…

I agree, SHA-2 is secure as far as we know. But since it's based on Merkle-Damgard, it permits length-extension attacks - i.e. given H(x), one can derive H(pad(x) || y) without knowing x.

So we need to be careful not to use it in setting where that would be problematic. Or we can use it with workarounds, like double hashing (SHA-256d) or truncating its output.

SHA-3 is sponge based, so its output is always truncated, preventing length-extension attacks. So I think SHA-3 is a better default, though it's fine to use SHA-2 if you know what you're doing.

Re: SHA-3 Buffer Overflow

#72

Post by duskwuff » Fri, Oct 21, 2022, 12:58 AM UTC

dlubarov wrote: post #71

tptacek wrote: post #64

Earlier quoted context omitted.

No. The "rise in computing power" doesn't jeopardize SHA2. There are important design differences between SHA1 and SHA2 (here's where in my younger days I'd pretend that I could rattle off the implications of nonlinear message expansion off the top of my head). SHA2 is secure; don't take my word for it through, you can find one of the Blake2 designers saying SHA2 is unlikely ever to be broken, or Marc Stevens on a Tw…

I agree, SHA-2 is secure as far as we know. But since it's based on Merkle-Damgard, it permits length-extension attacks - i.e. given H(x), one can derive H(pad(x) || y) without knowing x. So we need to be careful not to use it in setting where that would be problematic. Or we can use it with workarounds, like double hashing (SHA-256d) or truncating its output. SHA-3 is sponge based, so its output is always truncated,…

Truncated SHA512 hashes, such as SHA512/256, defeat length extension attacks by omitting part of the hash state from the output. They're also significantly faster than classic SHA256 for large inputs.

Re: SHA-3 Buffer Overflow

#73

Post by baby » Fri, Oct 21, 2022, 1:06 AM UTC

aliqot wrote: post #6

Interesting they both say "Official Sha3" and "by its designers", which as I remember it isn't that accurate. Keccak was chosen and then NIST added what is affectionately known as the 'mystery padding' before certification. What we know as official is not the way the designers submitted the proposal. This isn't an attempt at a scary accusation, but as a pedant, this got me. For those wondering, here is an explanation…

I'm not sure what's your point, the XKCP is the official SHA-3 implementation.

Re: SHA-3 Buffer Overflow

#74

Post by baby » Fri, Oct 21, 2022, 1:14 AM UTC

duskwuff wrote: post #25

ajsfoux234 wrote: post #3

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

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

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

Re: SHA-3 Buffer Overflow

#75

Post by baby » Fri, Oct 21, 2022, 1:14 AM UTC

duskwuff wrote: post #72

dlubarov wrote: post #71

Earlier quoted context omitted.

I agree, SHA-2 is secure as far as we know. But since it's based on Merkle-Damgard, it permits length-extension attacks - i.e. given H(x), one can derive H(pad(x) || y) without knowing x. So we need to be careful not to use it in setting where that would be problematic. Or we can use it with workarounds, like double hashing (SHA-256d) or truncating its output. SHA-3 is sponge based, so its output is always truncated,…

Truncated SHA512 hashes, such as SHA512/256, defeat length extension attacks by omitting part of the hash state from the output. They're also significantly faster than classic SHA256 for large inputs.

Blake2/3 also doesn't suffer from length extension attacks, but SHA-256 is what everyone uses unfortunately.

Re: SHA-3 Buffer Overflow

#76

Post by baby » Fri, Oct 21, 2022, 1:15 AM UTC

jbaczuk wrote: post #61

no bounty and still politely reports it. Good guys need more praise.

it's a public standard, who would pay such a bounty?

Re: SHA-3 Buffer Overflow

#77

Post by baby » Fri, Oct 21, 2022, 1:17 AM UTC

metadat wrote: post #5

If you're familiar with SHA-256 and this is your first encounter with SHA-3: The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are: * Resistance to length extension attacks. * Performance. The SHA-2 functions—particularly SHA-512, SHA-512/224, and SHA-512/256—generally have higher performance than the SHA-3 functions. Partly this wa…

SHA-3 was also designed with hardware performance in mind IIRC, as in: if it becomes supported in hardware it will be much faster than SHA-2 hardware support.

Re: SHA-3 Buffer Overflow

#78

Post by all_these_years » Fri, Oct 21, 2022, 1:24 AM UTC

SHA-3 in Ruby:

    $ gem install sha3
    $ irb
      > require 'sha3'
      > s = SHA3::Digest::SHA224.new
      > s.update("\x00")
      > s.update("\x00" * 4294967295)

    [ Segmentation fault... ]

Tested with Ruby 3.1.2

Gem's code (including C native extension): https://github.com/johanns/sha3

Re: SHA-3 Buffer Overflow

#79

Post by halostatue » Fri, Oct 21, 2022, 1:50 AM UTC

duskwuff wrote: post #25

ajsfoux234 wrote: post #3

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

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

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

Re: SHA-3 Buffer Overflow

#80

Post by adrian_b » Fri, Oct 21, 2022, 2:11 AM UTC

franky47 wrote: post #62

metadat wrote: post #5

If you're familiar with SHA-256 and this is your first encounter with SHA-3: The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are: * Resistance to length extension attacks. * Performance. The SHA-2 functions—particularly SHA-512, SHA-512/224, and SHA-512/256—generally have higher performance than the SHA-3 functions. Partly this wa…

Note that truncated SHA-2 (SHA-224, SHA-384, SHA-512/224, SHA-512/256) are not susceptible to length-extensions attacks [1]. With the added benefit of better performance of SHA-512 (on 64 bit systems) [2], there's no good reason to use SHA-256 rather than SHA-512/256 for new cryptographic designs. [1] https://en.wikipedia.org/wiki/Length_extension_attack [2] https://crypto.stackexchange.com/questions/26336/sha-512-fa…

There is a good reason to use SHA-256 and not SHA-512.

Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512.

Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3.

Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash algorithms based on the detected CPU.

On old 64-bit CPUs without SHA hardware, e.g. Intel Skylake, SHA-512 is faster than SHA-256 (Intel introduced SHA in Atom CPUs many years before also introducing it in Core CPUs, so that Atom could compete in Geekbench scores with the ARM CPUs, which already had SHA).