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...
show comments
maqp
Would've been interesting to see something about when to use MLKEM-1024-X448 and ML-DSA-87-ed448.
BoppreH
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".
hdmoore
Hurray for mostly-non-controversial opinions!
show comments
pluto_modadic
Okay - so... they're saying... don't use p384? :3
show comments
commandersaki
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.
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...
Would've been interesting to see something about when to use MLKEM-1024-X448 and ML-DSA-87-ed448.
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.