4 ms·

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefi

by ktta 9y ago

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefits. BLAKE2 is a good candidate right now considering speed. But SHA-256 instructions will only get more prevalent which will take care of the speed issue. There have been speed comparisons between SHA-256 and BLAKE2 without SHA instructions[1]. BLAKE2 seems like good option then, with the optimized code. But once SHA extensions use hardware instructions, it gets a 5.7x boost which blows BLAKE2 out of the water.[2] There are instructions for SHA-256 in NEON too although I couldn't find any benchmarks. I'd say it'll definitely be faster than BLAKE2 with HW instructions. Combine that with SHA256 being uber popular everywhere, that'll be one less headache. I also doubt SHA-256 will be over thrown in the near future, atleast until SHA-3 instructions become commonplace, which I anticipate will take about a decade from now. [1]: https://news.ycombinator.com/item?id=14357197 https://news.ycombinator.com/item?id=14357197 [2]: https://github.com/randombit/botan/issues/807#issuecomment-270652403 https://github.com/randombit/botan/issues/807#issuecomment-2... EDIT: Looks like SHA-224 might be the best option, considering it has the same core with a truncated output which will make it immune to length-extension attacks.

tptacek 9y ago
The advantage to 224 or 512/256 is that they don't expose the full register state of the hash at output and thus, like Blake2 and SHA-3, aren't vulnerable to length-extension attacks: you can (though it would be idiosyncratic to do so) use a simple prefix MAC with them, rather than HMAC.
- baby 9y ago
  But people don't know that. That's why it is best to just push people towards sha-3 and have the in-house cryptographer decide when sha-2/blake2/kangarootwelve might be relevant for speed purposes.
  - tptacek 9y ago
    I agree that using prefix MACs with SHA-2 is a bad idea, for that reason, but since everyone uses HMAC already and since there are much faster MACs than KMAC, I don't think there's a clear argument for SHA-3 here. I'm just saying, if you're going to recommend one of the SHA-2's, it should probably be one of the truncated ones.
- ktta 9y ago
  You are right. I guess I'll rethink SHA-224. SHA-512/256 is faster in 64 bit computers but it can't really take advantage of the hardware instructions unlike SHA-224. Prefixing a MAC sounds like it'll work but I'm just wondering why complicate things.
  - SAI_Peregrinus 9y ago
    Prefix MAC doesn't mean prefix the MAC. It means make a MAC by prefixing a key and concatenating that onto the data to be tagged. Basically what KMAC does: H(K+pad||message). The truncated hash functions aren't vulnerable to length extension attacks, so using SHA2-512/256 is faster than HMAC with no loss in security AFAIK. Of course that "no loss in security" bit depends on a proper implementation. There are plenty of good library implementations of HMAC out there, and if you want a high speed MAC there's always Poly1305. But if all you have is SHA2 and don't need to interoperate with systems using HMAC, then this is a reasonably good way to go about it. It's certainly simpler than implementing HMAC on your own.
- RcouF1uZ4gsC 9y ago
  With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates. With 512/256 this is infeasible. Is this a real concern with 224 in practice?
  - tptacek 9y ago
    224 is 512/224.
    - ktta 9y ago
      Wait, so I was talking about SHA-224 which is SHA-256 truncated to 224 bits, not SHA-512 truncated to 224 bits. Nevertheless, does this mean SHA-224 is still susceptible to length extension attacks?
      - nialo 9y ago
        SHA-256 truncated to 224 bits is vulnerable to length extension attacks if the attacker can brute force the remaining 32 bits of the state. Some use cases will make this possible or practical, some will not. It depends on the details of the problem being solved.
    - RcouF1uZ4gsC 9y ago
      According to https://en.m.wikipedia.org/wiki/SHA-2 https://en.m.wikipedia.org/wiki/SHA-2 There is SHA 224 which has 256 bit internal state and SHA 512/224 which has 512 bit internal state. In my previous comment, I was referring to the former.
      - ReidZB 9y ago
        This is how it's defined in FIPS-180, more or less (SHA-224 is SHA-256/224). This confusion is why I like explicitly stating SHA-256/x or SHA-512/x.
  - baby 9y ago
    It sounds like you're right.
sdrapkin 9y ago
The best (ie. fastest and safest) SHA2-family function is SHA-384. http://securitydriven.net/inferno/#Implementation%20Details http://securitydriven.net/inferno/#Implementation%20Details
- ktta 9y ago
  *fastest in software on 64 bit platforms without hardware instructions. Note that it doesn't have the hardware instructions that are going to be common place for SHA-256 and SHA-224. Also if you have a 32-bit ARM phone (which is most phones in existence), it will take a hit on performance. That's because SHA-512 has 64-bit word size while SHA-256 has 32-bit word size. I thought I had the winner with SHA-256, but looks like I blanked on the fact that SHA-256 is susceptible to length extension attacks while the truncated versions of SHA2 are not. So I'll say SHA-224 is the optimal choice because even if you are running on 64 bit platforms, the hardware instructions will make it faster than SHA-512. Also insisting on higher security than SHA-256 is not a very smart move. SHA-256 offers more than enough security margin.

by ktta 9y ago

tptacek 9y ago

The advantage to 224 or 512/256 is that they don't expose the full register state of the hash at output and thus, like Blake2 and SHA-3, aren't vulnerable to length-extension attacks: you can (though it would be idiosyncratic to do so) use a simple prefix MAC with them, rather than HMAC.

baby 9y ago
But people don't know that. That's why it is best to just push people towards sha-3 and have the in-house cryptographer decide when sha-2/blake2/kangarootwelve might be relevant for speed purposes.
- tptacek 9y ago
  I agree that using prefix MACs with SHA-2 is a bad idea, for that reason, but since everyone uses HMAC already and since there are much faster MACs than KMAC, I don't think there's a clear argument for SHA-3 here. I'm just saying, if you're going to recommend one of the SHA-2's, it should probably be one of the truncated ones.
ktta 9y ago
You are right. I guess I'll rethink SHA-224. SHA-512/256 is faster in 64 bit computers but it can't really take advantage of the hardware instructions unlike SHA-224. Prefixing a MAC sounds like it'll work but I'm just wondering why complicate things.
- SAI_Peregrinus 9y ago
  Prefix MAC doesn't mean prefix the MAC. It means make a MAC by prefixing a key and concatenating that onto the data to be tagged. Basically what KMAC does: H(K+pad||message). The truncated hash functions aren't vulnerable to length extension attacks, so using SHA2-512/256 is faster than HMAC with no loss in security AFAIK. Of course that "no loss in security" bit depends on a proper implementation. There are plenty of good library implementations of HMAC out there, and if you want a high speed MAC there's always Poly1305. But if all you have is SHA2 and don't need to interoperate with systems using HMAC, then this is a reasonably good way to go about it. It's certainly simpler than implementing HMAC on your own.
RcouF1uZ4gsC 9y ago
With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates. With 512/256 this is infeasible. Is this a real concern with 224 in practice?
- tptacek 9y ago
  224 is 512/224.
  - ktta 9y ago
    Wait, so I was talking about SHA-224 which is SHA-256 truncated to 224 bits, not SHA-512 truncated to 224 bits. Nevertheless, does this mean SHA-224 is still susceptible to length extension attacks?
    - nialo 9y ago
      SHA-256 truncated to 224 bits is vulnerable to length extension attacks if the attacker can brute force the remaining 32 bits of the state. Some use cases will make this possible or practical, some will not. It depends on the details of the problem being solved.
  - RcouF1uZ4gsC 9y ago
    According to https://en.m.wikipedia.org/wiki/SHA-2 https://en.m.wikipedia.org/wiki/SHA-2 There is SHA 224 which has 256 bit internal state and SHA 512/224 which has 512 bit internal state. In my previous comment, I was referring to the former.
    - ReidZB 9y ago
      This is how it's defined in FIPS-180, more or less (SHA-224 is SHA-256/224). This confusion is why I like explicitly stating SHA-256/x or SHA-512/x.
- baby 9y ago
  It sounds like you're right.

sdrapkin 9y ago

The best (ie. fastest and safest) SHA2-family function is SHA-384. http://securitydriven.net/inferno/#Implementation%20Details http://securitydriven.net/inferno/#Implementation%20Details

ktta 9y ago
*fastest in software on 64 bit platforms without hardware instructions. Note that it doesn't have the hardware instructions that are going to be common place for SHA-256 and SHA-224. Also if you have a 32-bit ARM phone (which is most phones in existence), it will take a hit on performance. That's because SHA-512 has 64-bit word size while SHA-256 has 32-bit word size. I thought I had the winner with SHA-256, but looks like I blanked on the fact that SHA-256 is susceptible to length extension attacks while the truncated versions of SHA2 are not. So I'll say SHA-224 is the optimal choice because even if you are running on 64 bit platforms, the hardware instructions will make it faster than SHA-512. Also insisting on higher security than SHA-256 is not a very smart move. SHA-256 offers more than enough security margin.