Everywhere else in cryptography we favor recommendations that are harder to misuse, or that shrink the surface area of "things you have to think about and get right", but for some reason SHA-256 keeps finding its way into new designs (such as Git 3.0), even though things would be much nicer if I never had to remember that length extensions are a thing :/
On another note, as someone who defaults to BLAKE3 unless I have a good reason not to, it would be nice to have more context on Filippo's comment about it being very fast "but complex and uncommon enough that you want to have a good reason to use it and a good reason to trust your implementation".
I've peeked into the guts of Zig's BLAKE3 implementation before, it's merkle-tree-ish and not very scary looking, the primitives are a lot more recognizable than Keccak for example...
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.
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.
Filippo is my favorite way to keep myself abreast of the newest (professionally relevant!) drama in the cryptography community. As a colleague said today, "life is too short to read through all the TLS working group mailing list".
(There's a separate reason to be interested in "PQC" cryptography: even in the absence of a "full" classical break, most cryptographers agree that it's not ideal that all of our eggs are currently in one asymmetric cryptographic "basket," i.e. problems that generalize to the hidden subgroup problem. Asymmetric schemes whose hardness does not depend on a lack of solution to problems in that space seems like a reasonable thing to research and build.)
I think it's past time for this "Right Answers" cryptography meme to die, though. Filippo's PQC recommendations are good. Let's hope this is the last such document we ever need.
Politely disagree. I read Colin's when it came out and it was as useful in 2009 as Filippo's is today. If you only pay attention to the cryptography community every few years when you need it for something, then usually a whole lot has happened in the interval. It is incredibly useful to get the perspective of someone paying attention to give you a breakdown of "where we're at today".
A great example is the other conversation about SHA-256. Colin's recommendation was "hey, better plan to migrate from this in the future." The thing that's happened between then and now is, well, SHA-256 is actually still 'ok' when used in current constructions. That's useful to know in 2026.
If I get busy building stuff, it'll be nice to have a check-in again in a few years (or earlier if something significant happens first).
I hate passkeys and if your service doesn't offer an alternative then I'm not using your service.