(Post-Quantum) Cryptographic Right Answers
gavide
90 points
29 comments
October 12, 2026
Related Discussions
Found 5 related stories in 100.4ms across 9,270 title embeddings via pgvector HNSW
- How GPT‑5.6 Sol helps run quantum computing experiments theanonymousone · 145 pts · September 09, 2026 · 46% similar
- Discovering Cryptographic Weaknesses with Claude gslin · 200 pts · July 28, 2026 · 46% similar
- How Gödel's Proof Works (2020) tzury · 89 pts · August 13, 2026 · 44% similar
- Some thoughts about Anthropic's new cryptanalysis results supermatou · 129 pts · July 29, 2026 · 44% similar
- Qubes OS Security in the Public Record sciences44 · 86 pts · July 18, 2026 · 43% similar
Discussion Highlights (10 comments)
hdmoore
Hurray for mostly-non-controversial opinions!
paulnpace
Why can't I use rclone?
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. [0] https://www.youtube.com/watch?v=xa4Ok7WNFHY
zarzavat
> 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.
pluto_modadic
Okay - so... they're saying... don't use p384? :3
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".
luizfelberti
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...
maqp
Would've been interesting to see something about when to use MLKEM-1024-X448 and ML-DSA-87-ed448.
LVB
Will look back fondly to that period of short, ed25519 sigs…
meling
Have to say the I get a bit frustrated with all the acronyms in the cryptography space; it’s hard to keep up for those of us with a passing interest.