5 ms·

SHA-3 is currently a reasonable choice for effectively zero real world use-cases. SHA-2 has many advantages over it, and I can't think of a single disadvantage.

SHA-3 is currently a reasonable choice for effectively zero real world use-cases. SHA-2 has many advantages over it, and I can't think of a single disadvantage. SHA-3 has practical value as a moderately well-analyzed cipher in the event of rapid catastrophic cryptanalysis of SHA-2, but barring that kind of event its real value is in the general theoretical advancement of sponge constructions.

baby 9y ago
I think your mis using "world use case". It's a hash function and so it is usable as a hash function. I'll repeat what was said elsewhere. SHA-2 of vulnerable to length extension attacks.
- stouset 9y ago
  I said it's not a reasonable choice in the real world. Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead. Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC).
  - giovannibajo1 9y ago
    Being resistant to common misuses is indeed a feature in real world cryptography. We saw that with DSA where you leak the private key if you happen to reuse a nonce; yes, you shouldn't do that, but it's better to choose an algorithm that doesn't suffer from this in the first place. I'm not rooting for SHA-3; I'm just saying that it's wrong to dismiss length extension attacks only because they're commonly effective agains misuses of hash functions.
    - stouset 9y ago
      As tptacek points out elsewhere, if this is a concern for you, just use SHA-512/256. It's just as misuse-resistant, practically guaranteed to be in any library that would bother to implement SHA-3, faster by a mile, and has been the target of significantly more cryptanalysis. There are zero practical reasons to choose SHA-3.
  - baby 9y ago
    > Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead I don't see why, unless you're google and you care about small performance improvement in hash implementations. My point of view is that SHA-3 (or Blake2/K12) are THE hash functions you should use virtually anywhere. > Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC). Two things: 1) so what? People actually use it this way. Are you just going to say "oh they're using it wrong there is nothing we can do about it"? 2) why is it wrong to use a hash to create a MAC? It is the most logic thing to do imo. The H(key | data) makes total sense to me. It is only when you know SHA-2's internals and their weaknesses that you realize you can't use it like that.
    - stouset 9y ago
      A cryptographic operation making sense to you doesn't make it reasonable. H(password) makes sense to a lot of people, but we're not going to sub in Argon2 for every use of a hash function as a result. I'm with you on BLAKE2 as a solid choice, but at least it has an advantage in some areas over SHA-2 (speed, margin of security). SHA-3 has no advantages over SHA-2 (particularly SHA-512/256, which is going to be available in any library that would bother to implement SHA-3). SHA-3 is slower, has been the result of less cryptanalysis, has less battle-tested implementations, and is less widely supported. Practically the only thing it has going for it is a higher number. You will be hard-pressed to find a respected cryptographer advocating general adoption of SHA-3 — being in the field, I'd wager you'll find 100 who encourage developers to choose SHA-2 for every one who backs SHA-3. Case in point, in this thread alone you have Colin Percival and Thomas Ptacek coming to the defense of SHA-2, not to mention Adam Langley authoring the original post.
      - baby 9y ago
        If your hash function behaves like a random oracle it should allow you to do h(key|data) hashing password requires more than a random oracle because of the input small entropy so your argument is moot. The fact that sha-3 has received less analyzis has already been debunked Here:https://twitter.com/aarontoponce/status/869973259969675264 https://twitter.com/aarontoponce/status/869973259969675264 . K12 has the advantage of the speed. See https://cryptologie.net/article/393/kangarootwelve/ https://cryptologie.net/article/393/kangarootwelve/ Appeal to authority does nothing. Plenty of people are actually supporting or making use of keccak/sha-3 already. To begin with NIST's cryptographers chose it. David Leon Gil was into it. People talked about heavy usages of SHA-3 in Ethereum or Chain here. I can tell you that one of the originator of SHA-3 created AES (Daemen). Jp aumasson (creator or blake2), samuel neves and philipp jovanovic are using sponges woth NORX. Mike Hamburg is building Strobe based on keccak. I can name drop as well you see. Plus I'll say that I support it as a wannabe cryptographer. That must count for something :D
- tptacek 9y ago
  ... if you use full-width SHA-2 256 or SHA-2 512. If you have enough design freedom to choose SHA-3, just use SHA-2 512/256.
  - deleted 9y ago
    [deleted]
- cperciva 9y ago
  SHA-2 of vulnerable to length extension attacks. SHA2 is vulnerable to length extension attacks the same way as bread is vulnerable to being buttered. If you're using bread and you're worried about buttering, you fundamentally misunderstand what bread is.
  - baby 9y ago
    I think you lost everyone here :D
    - krakensden 9y ago
      Hash functions have a pigeonhole principle problem, but that is also the point.
    - cperciva 9y ago
      If length extension attacks are a problem, you're using a hash function for something which a hash function is not intended to be used for; you probably wanted a MAC instead.
      - deleted 9y ago
        [deleted]
      - 15155 9y ago
        Why must MAC mean "HMAC RFC2104?"
        cperciva 9y ago
        It doesn't. I said MAC, not HMAC.
      - baby 9y ago
        1. Yes. And people do that. I'm nkt talking about me. I'm talking about things I see in my work (I'm a consultant). 2. People should be able to do that. If you're expecting your hash function to behave somehow like a random oracle there is no reason that h(key|data) doesn't work. I see people using sha-2 to derive keys all the time. Even this is unsafe depending on how you do it.

baby 9y ago

I think your mis using "world use case". It's a hash function and so it is usable as a hash function. I'll repeat what was said elsewhere. SHA-2 of vulnerable to length extension attacks.

stouset 9y ago
I said it's not a reasonable choice in the real world. Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead. Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC).
- giovannibajo1 9y ago
  Being resistant to common misuses is indeed a feature in real world cryptography. We saw that with DSA where you leak the private key if you happen to reuse a nonce; yes, you shouldn't do that, but it's better to choose an algorithm that doesn't suffer from this in the first place. I'm not rooting for SHA-3; I'm just saying that it's wrong to dismiss length extension attacks only because they're commonly effective agains misuses of hash functions.
  - stouset 9y ago
    As tptacek points out elsewhere, if this is a concern for you, just use SHA-512/256. It's just as misuse-resistant, practically guaranteed to be in any library that would bother to implement SHA-3, faster by a mile, and has been the target of significantly more cryptanalysis. There are zero practical reasons to choose SHA-3.
- baby 9y ago
  > Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead I don't see why, unless you're google and you care about small performance improvement in hash implementations. My point of view is that SHA-3 (or Blake2/K12) are THE hash functions you should use virtually anywhere. > Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC). Two things: 1) so what? People actually use it this way. Are you just going to say "oh they're using it wrong there is nothing we can do about it"? 2) why is it wrong to use a hash to create a MAC? It is the most logic thing to do imo. The H(key | data) makes total sense to me. It is only when you know SHA-2's internals and their weaknesses that you realize you can't use it like that.
  - stouset 9y ago
    A cryptographic operation making sense to you doesn't make it reasonable. H(password) makes sense to a lot of people, but we're not going to sub in Argon2 for every use of a hash function as a result. I'm with you on BLAKE2 as a solid choice, but at least it has an advantage in some areas over SHA-2 (speed, margin of security). SHA-3 has no advantages over SHA-2 (particularly SHA-512/256, which is going to be available in any library that would bother to implement SHA-3). SHA-3 is slower, has been the result of less cryptanalysis, has less battle-tested implementations, and is less widely supported. Practically the only thing it has going for it is a higher number. You will be hard-pressed to find a respected cryptographer advocating general adoption of SHA-3 — being in the field, I'd wager you'll find 100 who encourage developers to choose SHA-2 for every one who backs SHA-3. Case in point, in this thread alone you have Colin Percival and Thomas Ptacek coming to the defense of SHA-2, not to mention Adam Langley authoring the original post.
    - baby 9y ago
      If your hash function behaves like a random oracle it should allow you to do h(key|data) hashing password requires more than a random oracle because of the input small entropy so your argument is moot. The fact that sha-3 has received less analyzis has already been debunked Here:https://twitter.com/aarontoponce/status/869973259969675264 https://twitter.com/aarontoponce/status/869973259969675264 . K12 has the advantage of the speed. See https://cryptologie.net/article/393/kangarootwelve/ https://cryptologie.net/article/393/kangarootwelve/ Appeal to authority does nothing. Plenty of people are actually supporting or making use of keccak/sha-3 already. To begin with NIST's cryptographers chose it. David Leon Gil was into it. People talked about heavy usages of SHA-3 in Ethereum or Chain here. I can tell you that one of the originator of SHA-3 created AES (Daemen). Jp aumasson (creator or blake2), samuel neves and philipp jovanovic are using sponges woth NORX. Mike Hamburg is building Strobe based on keccak. I can name drop as well you see. Plus I'll say that I support it as a wannabe cryptographer. That must count for something :D
tptacek 9y ago
... if you use full-width SHA-2 256 or SHA-2 512. If you have enough design freedom to choose SHA-3, just use SHA-2 512/256.
- deleted 9y ago
  [deleted]
cperciva 9y ago
SHA-2 of vulnerable to length extension attacks. SHA2 is vulnerable to length extension attacks the same way as bread is vulnerable to being buttered. If you're using bread and you're worried about buttering, you fundamentally misunderstand what bread is.
- baby 9y ago
  I think you lost everyone here :D
  - krakensden 9y ago
    Hash functions have a pigeonhole principle problem, but that is also the point.
  - cperciva 9y ago
    If length extension attacks are a problem, you're using a hash function for something which a hash function is not intended to be used for; you probably wanted a MAC instead.
    - deleted 9y ago
      [deleted]
    - 15155 9y ago
      Why must MAC mean "HMAC RFC2104?"
      - cperciva 9y ago
        It doesn't. I said MAC, not HMAC.
    - baby 9y ago
      1. Yes. And people do that. I'm nkt talking about me. I'm talking about things I see in my work (I'm a consultant). 2. People should be able to do that. If you're expecting your hash function to behave somehow like a random oracle there is no reason that h(key|data) doesn't work. I see people using sha-2 to derive keys all the time. Even this is unsafe depending on how you do it.