Filippo Valsorda
RC F'13, F2'17
Cryptogopher / Go cryptography maintainer
Geomys founder (https://geomys.org)
https://mkcert.dev / https://age-encryption.org / https://sunlight.dev
🕳️ “Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.” —@nickm@abyssdomain.expert
I used to be very good at playing the getting-hired and negotiation games, on behalf of myself and others.
Times have changed, and I've probably lost the pulse, but now, like back then, a big part is understanding what game the other side is playing.
This is a very good post to read for early- and mid-career folks: https://lobste.rs/s/mroowi/being_kicked_out_tech_industry#c_tvw4yk
Two papers came out last week that suggest classical asymmetric cryptography might indeed be broken by quantum computers in just a few years.
That means we need to ship post-quantum crypto now, with the tools we have: ML-KEM and ML-DSA. I didn't think PQ auth was so urgent until recently.
Ok, I think the ML-DSA performance side quest might be complete 🏎️
Very proud of how safe and clear the final incremental changes are, too.
ML-KEM and ML-DSA fill matrices/vectors with output from SHAKE, each element derived from slightly different inputs.
This is perfect for SIMD instructions, so now we have
func ReadMulti(s []*SHAKE, out [][]byte)
backed by AVX2 on amd64, and by the existing two-lane asm on arm64.
I am so happy we can now divinate precise diagrams in minutes to help reason through complicated code.
(This is the "butterfly" of the Number Theoretic Transform used in ML-DSA. You can make it a lot faster by not reducing non-overflowing intermediate states, but I had to convince myself that they do not, in fact, overflow.)
Alright, it's official! 💰
@matthew_d_green@ioc.exchange and I bet on what will break first, ML-KEM-768 or X25519. The loser donates to a 501(c)(3) picked by the winner.
If you have an opinion on quantum computers or lattices, you can join with a side bet. Just submit a PR!
Oh hey, with all the 🔥 I almost missed that today was the 12th anniversary of Heartbleed.
The online test I cobbled together that night gave me the opportunities to get started in this line of work!
Initially it was hilariously bad: a Flask server shelling out to a patched Go crypto/tls binary.
There are no technical or compliance reasons to double the size of symmetric keys in response to the threat of quantum computers.
This common misunderstanding of Grover's algorithm risks wasting limited resources that should go towards deploying actually urgent post-quantum algorithms.
Looks like GitHub silently corrupted some index.
PR #237 definitely exists and is closed (https://github.com/C2SP/C2SP/pull/237) but is just... not in the list (https://github.com/C2SP/C2SP/pulls?q=is%3Apr+is%3Aclosed) regardless of filters.
I briefly doubted my own sanity. This is bad.
How much storage / bandwidth / CPU / memory does it take to run a production Sunlight CT log? Surprisingly little!
There's now a public stats page, pulled every 5m from our Tuscolo prod metrics.
https://stats.sunlight.geomys.org/
Less than 2 cores, 300 MB of memory, ~250 Mbps of bandwidth, 260 GiB of SSD.
Last year, my position was that we still had time to design PQ authentication mechanisms.
Now, based on the pace of progress and on statements like Google's, I believe:
1. we need to finish rolling out PQ key exchange yesterday
2. we need to start rolling out PQ auth now
3. it's too late to ship any new non-PQ design or system
https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
Can you see how to use a test vector that provides (seed, public key, message, µ, signature) to test a deterministic signing API that does (seed, message) → (signature) or a key generation API that does (seed) → (public key)?
Noted cryptographer D. J. Bernstein can't, certainly in good faith.
*sigh*
I jest, but refuting this FUD takes real resources we could spend so, so, so much better. It'd be sad if it wasn't so harmful.
https://mailarchive.ietf.org/arch/msg/tls/p5j6UCQGBAOblWPAjXb5ycMjxA4/
There's been some confusion around some BRs non-compliant X.509 chains that OpenSSL accepts but Go rejects.
We're not going to introduce complexity in crypto/x509 to support them, but I realized you could always re-encode the issuer as an unsigned root to work around it.
So I made a little web tool to make it easy.
https://github.com/golang/go/issues/31440#issuecomment-4663196149
There was no good way to see what CT logs are actually used by CAs, so I made a dashboard of Censys data on exe.dev.
There are some interesting patterns, but the main one is that Let's Encrypt is the only CA that evenly spreads load. Other CAs are mostly using older logs, or their own logs and Google's.
(Of course, LE is 50% of issuance, and GTS is 25%, so the rest don't matter much.)
RE: @sophieschmieg@infosec.exchange
Yay test vectors!
I will write properly about this, but we are going pretty far to test ML-DSA *and make it easy to test,* so I am hopeful ML-DSA bugs will be rare compared to classical [EC|Ed]DSA bugs.
These test gaps were identified by writing multiple alternative ML-DSA implementations and mutation testing *those* to find missing vectors to then bring back to the Go implementation, and share on Wycheproof.
I finally chased down test coverage for the last edge cases of ML-DSA's low-level, constant-time field operations like Decompose.
This is an accumulated (https://words.filippo.io/accumulated/) test that locks in the output for all possible inputs of all these tricky functions. https://go.dev/cl/762940
It's not even that slow (5.27s)!
Also available on CCTV, along with accumulated keygen/sign/verify tests worth 60M random tests: https://github.com/C2SP/CCTV/tree/main/ML-DSA/accumulated
NIST is updating SP 800-133, which details the "FIPS approved" ways to generate keys.
There's a lot of good news in it, it approves a lot of stuff we were doing, like X-Wing seed derivation and https://c2sp.org/det-keygen.
Here are my comments: https://leaflet.pub/f6fc0b3b-161d-4e35-99cd-e95ad62402a5
A brief timeline of the Go FIPS 140-3 validation:
- February 2024: first prospectus
- March 2024: started working with lab
- July 2024: first contract
- September 2024: opened issue
- January 2025: froze module
- May 2025: submitted validation
- April 2026: certificate issued
I am live with Alex Gaynor to talk about the Geomys model of professional open source maintenance and how it helps projects face challenges, like the recent influx of LLM vulnerability findings!
Join us live on https://www.twitch.tv/filosottile right now or catch the recording soon!
TIL about the git fast-import textual format!
Lets me write tests for the c2sp.org redirector against a synthetic git repository I can easily edit, and even gives me stable shorthands to refer to commits.
https://github.com/C2SP/C2SP/commit/99d43ad2adcddb85acf37028be45590cd78008c3



