upvote
Because length extension attacks only matter if you're doing something you should never be doing: hand-rolling your own keyed hash constructions. Everybody uses HMAC (you even see it in SHA3 systems), and so length extension doesn't matter. Meanwhile, SHA2 has hardware support.

I like BLAKE3 just fine. Nobody's really going to ding you for using it (or SHA3 for that matter). But it would not be sound practice to tear SHA2 out of a system that was already using it.

Two other notes:

(1) The article explicitly recommends HMAC-SHA2, not SHA2 by itself.

(2) Where it does recommend SHA2 directly (for hashing, not authentication), it recommends 512/256, which is truncated and can't be length-extended.

reply
I think the original comment still stands though right? You can hand roll a keyed hash if you use sha3 or a truncated sha2. It saves you having to do two hash operations
reply
You shouldn't do that even with SHA3; SHA3 KMAC isn't literally just secret-prefix keyed SHA3, it has a bunch of encoding things (like commitment to message length). You should essentially never be hand-rolling an authenticator.
reply
Length extension attacks are only one of the issues you can run into, so even if you use SHA3 or truncated SHA2 as your hash primitive you still shouldn't be rolling your own keyed hash construction.

The article references this as "YoloMAC" with a link to a pretty good Trail of Bits blogpost about it. But the TLDR is that just prepending the key to the message can lead to ambiguous encoding problems, so you still need to add extra complexity to your hand rolled keyed hash to handle things that the underlying hash primitive isn't going to protect you from on it's own. You're better off using a non-hand-rolled construction that protects against all the things including length extension.

reply
Because the MD length extension attacks only show up in a fairly limited set of cases and have mitigations which are considered bog standard (e.g. HMAC). If you're doing something where a MD length extension attack would harm you ... you're already lost in the dark and are going to be eaten by a grue-- avoiding SHA-256 will not save you.

Swapping out sha256 with something else when you would have had an extension attack means you're probably going to flub domain separation or miss committing to segment lengths or something else that is an inherent footgun that can't be misuse resistance your way out of but which harder to get right and more easily consequential than avoiding MD extensions.

Misuse resistance is important for sure, but the MD length extension is not in the same fragility class as stuff like 'relied on the caller to provide randomness for ECDSA'. And the hardware implementations of SHA256 have quite good energy efficiency and the algorithm overall has held up exceptionally well.

reply