4 ms·

SHA3 is fine but it's so slow, I don't many people that use it

xeyownt 3y ago
Slow? Fastest in HW, and comparable performance in SW. Moreover if you take into account security hardening, SHA3 is easier to protect than alternatives.
- lazide 3y ago
  Faster than Blake2/3? Not even close!
  - throw0101c 3y ago
    > Faster than Blake2/3? Not even close! Blake2 was not created (December 2012) until after the SHA-3 competition, which ended on October 2012 (Keccak being the winner). It was Blake1 that was entered. Blake3 was released in 2020. I'm sure a Keccak2/3 could have also been better than the original Keccak1, but that was not available either.
    - lazide 3y ago
      You never specified timing. You made a blanket statement as if it was still true.
- tux3 3y ago
  Comparable in software, to what? Password hashes? :)
- formerly_proven 3y ago
  Last I checked SHA3-512 is like 4x slower than SHA2-512 on x86.
  - throw0101c 3y ago
    And SHA-1 is faster than SHA-2, with MD5 faster than both. But speed isn't the only reason to choose an algorithm.
    - AlexandrB 3y ago
      As a non cryptographer this whole conversation chain has me confused. I though it was desirable for a good hashing algorithm to be slow to make brute force difficult.
      - deleted 3y ago
        [deleted]
      - Tainnor 3y ago
        That's true for passwords (where you don't really use raw SHA or something, but rather something like bcrypt which is intentionally slow), not necessarily for all uses of passwords. E.g. computing a SHA sum of some binary doesn't need to be slow, it just has to be practically impossible to create a collision (which is what's required of every good cryptographic hash function).
      - oconnor663 3y ago
        Yeah this is a super common point of confusion. You need to worry about slowing down a brute force attacker when you're trying to protect a low-entropy secret, which basically always means user passwords. But when your secrets are big enough, like 128 bits, brute force becomes impossible just by virtue of the size of the search space. So for most cryptographic applications, it's the size of your key (and the fact that your hash or cipher doesn't _leak_ the key) that's protecting you from brute force, not the amount of time a single attempt takes.
      - conradludgate 3y ago
        Yeah SHA3 isn't directly for password hashing. You should use a memory strong PBKDF (password based key derivation function) like Argon2, bcrypt, or scrypt. These functions are all constructions that run the hash many times, so the underlying hash speed is irrelevant For high entropy inputs, like for a HMAC signature, you want the hash to be fast because its practically impossible to brute force the 256bit input key, and you often apply this to large inputs.
edflsafoiewq 3y ago
SHA3 is mostly a hedge for the risk SHA2 is broken.

Slow? Fastest in HW, and comparable performance in SW. Moreover if you take into account security hardening, SHA3 is easier to protect than alternatives.

lazide 3y ago
Faster than Blake2/3? Not even close!
- throw0101c 3y ago
  > Faster than Blake2/3? Not even close! Blake2 was not created (December 2012) until after the SHA-3 competition, which ended on October 2012 (Keccak being the winner). It was Blake1 that was entered. Blake3 was released in 2020. I'm sure a Keccak2/3 could have also been better than the original Keccak1, but that was not available either.
  - lazide 3y ago
    You never specified timing. You made a blanket statement as if it was still true.
tux3 3y ago
Comparable in software, to what? Password hashes? :)
formerly_proven 3y ago
Last I checked SHA3-512 is like 4x slower than SHA2-512 on x86.
- throw0101c 3y ago
  And SHA-1 is faster than SHA-2, with MD5 faster than both. But speed isn't the only reason to choose an algorithm.
  - AlexandrB 3y ago
    As a non cryptographer this whole conversation chain has me confused. I though it was desirable for a good hashing algorithm to be slow to make brute force difficult.
    - deleted 3y ago
      [deleted]
    - Tainnor 3y ago
      That's true for passwords (where you don't really use raw SHA or something, but rather something like bcrypt which is intentionally slow), not necessarily for all uses of passwords. E.g. computing a SHA sum of some binary doesn't need to be slow, it just has to be practically impossible to create a collision (which is what's required of every good cryptographic hash function).
    - oconnor663 3y ago
      Yeah this is a super common point of confusion. You need to worry about slowing down a brute force attacker when you're trying to protect a low-entropy secret, which basically always means user passwords. But when your secrets are big enough, like 128 bits, brute force becomes impossible just by virtue of the size of the search space. So for most cryptographic applications, it's the size of your key (and the fact that your hash or cipher doesn't _leak_ the key) that's protecting you from brute force, not the amount of time a single attempt takes.
    - conradludgate 3y ago
      Yeah SHA3 isn't directly for password hashing. You should use a memory strong PBKDF (password based key derivation function) like Argon2, bcrypt, or scrypt. These functions are all constructions that run the hash many times, so the underlying hash speed is irrelevant For high entropy inputs, like for a HMAC signature, you want the hash to be fast because its practically impossible to brute force the 256bit input key, and you often apply this to large inputs.

edflsafoiewq 3y ago

SHA3 is mostly a hedge for the risk SHA2 is broken.