3 ms·

I'd also throw in that HMAC is overrated. It's a workaround for bad hash algorithms that are vulnerable to length-extension attacks. If you're using a "good"

by notfed 2y ago

I'd also throw in that HMAC is overrated. It's a workaround for bad hash algorithms that are vulnerable to length-extension attacks. If you're using a "good" hash algorithm, then MAC-ing is simple: hash over your key and message. It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack. Anyway, in general it's a pet peeve of mine that many people so often say "HMAC" when really they just mean MAC.

nmadden 2y ago
Yes and no. HMAC is very inefficient for short messages, but that inefficiency quickly vanishes into noise for anything over a kB or two. (HKDF and HMAC-DRBG are probably the worst offenders as they are always running HMAC on small inputs). But, on the other hand, HMAC has repeatedly proven itself to be resilient to all kinds of attacks. I definitely didn’t mean any MAC when I recommended HMAC: eg I don’t think Poly1305 is a good general purpose MAC. PRF maybe, but sometimes you need the MAC to be committing too. Yes, some hash functions can be used with a simple prefix MAC, but then you need to list which specific hash functions to use (and most of those are not yet widely available).
skrebbel 2y ago
> It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack. A bit of a tangent, but I didn't know this, so thanks for pointing this out. It's insane to me that there's two SHA hash algorithms that result in a 256 bit string, named nearly identically, but the one is vulnerable to a length-extension attack but the other isn't. I had simply assumed that SHA-256 and SHA-512 are the exact same thing except the length of the result. Wouldn't anyone? The length of the result is right there in the name! I mean why does SHA-256 even exist when SHA-512/256 is what we should all use? Why does a single library implement an algorithm that everybody in crypto land, apparently (if you're right), already knew was broken from the start? Give the good one the short name and keep the bad one out of codebases! Come on! Crypto is hard but crypto people keep making it harder and I hate it.
- dspillett 2y ago
  > why does SHA-256 even exist when SHA-512/256 is what we should all use? SHA-512 is more computationally costly so running that and truncating the result is slower than just running SHA-256. Where performance is key¹ and you have other protection in your protocol that mitigates extension issues, that could be a significant benefit. IIRC SHA512 used 64-bit values throughout rather than 32 as used in SHA256, so it might actually be faster on software on modern 64-bit architectures, nullifying the above consideration on such platforms, but back when the SHA2 family were formally specified 64-bit processing was far far less common. Also if you have acceleration for SHA256 in hardware but not 512 that flips things back. Hardware support for SHA256 will be cheaper in silicon than SHA512. ---- [1] very low CPU power systems, or hashing en-mass on now powerful arrangements
  - NovemberWhiskey 2y ago
    >SHA-512 is more computationally costly In fact, as you suggested later, SHA-512 is actually much less computationally expensive on 64 bit machines - it has 25% more rounds, but you can do twice the number of bytes per round. All other things being equal (which they seldom are), you will often see a significant speed improvement with SHA-512 vs. SHA-256 on larger payloads. Of course, I immediately tried to test this with "openssl speed" on my M1 Mac and SHA-512 is 70% slower, so I guess there's some architectural optimization there.
    - mtndew4brkfst 2y ago
      Can the algorithm benefit from SIMD/AVX512? Not helpful for ARM Macs, I have one too, but might be a contributing factor to lower adoption since those instructions aren't as widespread. First consumer chips in ~2017 and first AMD chips in ~2022.
      - NovemberWhiskey 2y ago
        I did a quick check on a 2016-era Xeon E5 v4 (AVX2), and sha512 is much faster per openssl speed.
tptacek 2y ago
You're pointing out that SOTA hashes like SHA3 and Blake2 aren't length-extendable, which is true, but KMAC is more than simply keyed SHA3; it's also domain-separated.

by notfed 2y ago

nmadden 2y ago

Yes and no. HMAC is very inefficient for short messages, but that inefficiency quickly vanishes into noise for anything over a kB or two. (HKDF and HMAC-DRBG are probably the worst offenders as they are always running HMAC on small inputs). But, on the other hand, HMAC has repeatedly proven itself to be resilient to all kinds of attacks. I definitely didn’t mean any MAC when I recommended HMAC: eg I don’t think Poly1305 is a good general purpose MAC. PRF maybe, but sometimes you need the MAC to be committing too. Yes, some hash functions can be used with a simple prefix MAC, but then you need to list which specific hash functions to use (and most of those are not yet widely available).

skrebbel 2y ago

> It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack. A bit of a tangent, but I didn't know this, so thanks for pointing this out. It's insane to me that there's two SHA hash algorithms that result in a 256 bit string, named nearly identically, but the one is vulnerable to a length-extension attack but the other isn't. I had simply assumed that SHA-256 and SHA-512 are the exact same thing except the length of the result. Wouldn't anyone? The length of the result is right there in the name! I mean why does SHA-256 even exist when SHA-512/256 is what we should all use? Why does a single library implement an algorithm that everybody in crypto land, apparently (if you're right), already knew was broken from the start? Give the good one the short name and keep the bad one out of codebases! Come on! Crypto is hard but crypto people keep making it harder and I hate it.

dspillett 2y ago
> why does SHA-256 even exist when SHA-512/256 is what we should all use? SHA-512 is more computationally costly so running that and truncating the result is slower than just running SHA-256. Where performance is key¹ and you have other protection in your protocol that mitigates extension issues, that could be a significant benefit. IIRC SHA512 used 64-bit values throughout rather than 32 as used in SHA256, so it might actually be faster on software on modern 64-bit architectures, nullifying the above consideration on such platforms, but back when the SHA2 family were formally specified 64-bit processing was far far less common. Also if you have acceleration for SHA256 in hardware but not 512 that flips things back. Hardware support for SHA256 will be cheaper in silicon than SHA512. ---- [1] very low CPU power systems, or hashing en-mass on now powerful arrangements
- NovemberWhiskey 2y ago
  >SHA-512 is more computationally costly In fact, as you suggested later, SHA-512 is actually much less computationally expensive on 64 bit machines - it has 25% more rounds, but you can do twice the number of bytes per round. All other things being equal (which they seldom are), you will often see a significant speed improvement with SHA-512 vs. SHA-256 on larger payloads. Of course, I immediately tried to test this with "openssl speed" on my M1 Mac and SHA-512 is 70% slower, so I guess there's some architectural optimization there.
  - mtndew4brkfst 2y ago
    Can the algorithm benefit from SIMD/AVX512? Not helpful for ARM Macs, I have one too, but might be a contributing factor to lower adoption since those instructions aren't as widespread. First consumer chips in ~2017 and first AMD chips in ~2022.
    - NovemberWhiskey 2y ago
      I did a quick check on a 2016-era Xeon E5 v4 (AVX2), and sha512 is much faster per openssl speed.

tptacek 2y ago

You're pointing out that SOTA hashes like SHA3 and Blake2 aren't length-extendable, which is true, but KMAC is more than simply keyed SHA3; it's also domain-separated.