Rendered at 23:47:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
luizfelberti 3 hours ago [-]
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...
tptacek 3 hours ago [-]
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.
djohnmustard 2 hours ago [-]
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
tptacek 1 hours ago [-]
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.
rainsford 1 hours ago [-]
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.
nullc 7 minutes ago [-]
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.
BoppreH 4 hours ago [-]
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".
maqp 2 hours ago [-]
Would've been interesting to see something about when to use MLKEM-1024-X448 and ML-DSA-87-ed448.
LVB 1 hours ago [-]
Will look back fondly to that period of short, ed25519 sigs…
hdmoore 9 hours ago [-]
Hurray for mostly-non-controversial opinions!
forty 2 hours ago [-]
DJB would like to have a word with you ;) (I'm not sure if this article is not even a semi-troll ^^ - not that especially disagree with it though)
pluto_modadic 4 hours ago [-]
Okay - so... they're saying... don't use p384? :3
woodruffw 4 hours ago [-]
As far as I know, P384 has never been a “right answer.”
commandersaki 5 hours ago [-]
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.
Guttman's talk is entertaining, but his argument around attacker behavior does not hold water: the attacker persona who is willing to do something very noisy (like use SQL injection on a server) is not the same persona that's interested in cryptographic breaks. OWASP measures the former, not the latter.
commandersaki 2 hours ago [-]
I didn't really find that the interesting part; more the (lack of) progress in cryptanalysis. I know there's been some brouhaha over the last few months that there's a target date for a CRQC (cryptographically relevant quantum computer) circa 2030. Rather than quibble about how it's feasible or how we should heed the threat, I'd rather just put money on it -- happy to bet anyone interested using the longbets platform.
woodruffw 1 hours ago [-]
I don't really have a dog in the CRQC fight. But reasoning abductively: every cryptography I know is at least abstractly concerned about classical breaks, particularly within the last 18 months.
(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.)
commandersaki 42 minutes ago [-]
My problem is the hype and fearmongering surrounding PQ is that it's taken away mindshare and resources that could be used for more relevant things in the cryptography community like more better/useful primitives and schemes. I'm not saying that there shouldn't be attention coming up with PQC schemes but it shouldn't hog all the attention and be foisted everywhere. But again, I'm not seeing the classic crypto doomerism everyone else spouts.
paulnpace 5 hours ago [-]
Why can't I use rclone?
tptacek 3 hours ago [-]
This gets into the weird history of these "Right Answers" documents, which I deeply regret ever help make into a thing. Colin Percival wrote the first one, in the long-long-ago, and he's the author of Tarsnap, a (very good) encrypted backup service. I wrote the next "Right Answers" document as a response to Percival's, because I felt his "Right Answers" were very idiosyncratic and wanted to put conservative normie answers on the record. Because I like Colin (and Tarsnap), my "Right Answers" had a Tarsnap recommendation, and so have subsequent ones.
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.
thadt 2 hours ago [-]
> I think it's past time for this "Right Answers" cryptography meme to die, though.
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).
doomrobo 5 hours ago [-]
rclone isn't a backup tool, it's a file transfer tool
commandersaki 5 hours ago [-]
Never heard of rclone but probably not a Cryptographic right answer because encryption isn't always on.
zarzavat 4 hours ago [-]
> 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.
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.
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.
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".
[0] https://www.youtube.com/watch?v=xa4Ok7WNFHY
(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.