(Post-Quantum) Cryptographic Right Answers

I really never managed to understand why we keep suggesting SHA-256 even though we know it's vulnerable to length extension attacks?

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...

Excellent post as always.

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".

Hurray for mostly-non-controversial opinions!

Okay - so... they're saying... don't use p384? :3

Meh don't care about the actual PQ parts. I'm with Peter Gutmann [0] in that PQ is just a waste of time and draining resources that could be put to better use.

[0] https://www.youtube.com/watch?v=xa4Ok7WNFHY

Why can't I use rclone?

> Password handling: Argon2id or scrypt. But have you considered passkeys instead?

I hate passkeys and if your service doesn't offer an alternative then I'm not using your service.