FiloSottile

How do you do revocation or software updates securely if your current signature algorithm is compromised?

That was my position until last year, and pretty much a consensus in the industry.

What changed is that the new timeline might be so tight that (accounting for specification, rollout, and rotation time) the time to switch authentication has also come.

ML-KEM deployment is tangentially touched on in the article because it's both uncontroversial and underway, but:

> This is not the article I wanted to write. I’ve had a pending draft for months now explaining we should ship PQ key exchange now, but take the time we still have to adapt protocols to larger signatures, because they were all designed with the assumption that signatures are cheap. That other article is now wrong, alas: we don’t have the time if we need to be finished by 2029 instead of 2035.

> For key exchange, the migration to ML-KEM is going well enough but: 1. Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because it’s very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years. [...]

You comment is essentially the premise of the other article.

If you want something book-shaped, the 2nd edition of Serious Cryptography is updated to when the NIST standards were near-final drafts, and has a nice chapter on post-quantum cryptography.

If you want something that includes details on how they were deployed, I'm afraid that's all very recent and I don't have good references.

That’s a fun list, the only hits in the top 100 are actually Cloudflare, for whom automatic DNSSEC is a feature, and would be a bad look not to dogfood it.

(I did a lot of the work of shipping that product in a past life. We had to fight the protocol and sometimes the implementers to beat it into something deployable. I am proud of that work from a technical point of view, but I agree DNSSEC adds little systemic value and haven’t thought about it since moving on from that project almost 10 years ago. It doesn’t look like DNSSEC itself has changed since, either.)

Then a few government sites, which have mandated it. The first hit after those is around #150.

For regular updates, because you can minimize but not eliminate risk. As I say in the article that might or might not work for your requirements and practices. For libraries, you also cause compounding churn for your dependents.

For security vulnerabilities, I argue that updating might not be enough! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have the bandwidth to do proper triage is by first minimizing false positives.

> I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones

Yeah, same. FWIW, geomys/sandboxed-step goes out of its way to use the GitHub Immutable Releases to make the git tag hopefully actually immutable.

All of these small block ciphers have regularly large keys.

I would love to learn more. What's the package integrity story of Java and .NET?

All I can find is documentation about artifacts on e.g. Maven Central being signed with any PGP key, which can freely change across package versions. If that's correct, it's no more than a convoluted checksum (without anything resembling the Checksum Database and its transparency log). If that's not correct, I am very curious what the workflow is when a package author loses a key.

Or, more concretely: what's stopping Maven Central from serving a fake version of someone else's package to a targeted victim?

There is no criticism of GitHub in the post, aside from throwing a bit of shade at them using mutable git tags for Actions instead of actually building a package manager.

The lack of verification of ecosystem-specific authenticity is natural, as the post says, in reading source directly from any code host.

NPM has the same problem if you click through to the source repository and expect what you read to match the package. It’s been used to hide attacks in that ecosystem in the same way, and the NPM web UI recently added a code browser similar to the one in this post.

If anything, the extra upload step of NPM (and similar centralized registries) makes things worse by encouraging and normalizing publishing different source from what is in the VCS.

(Also, Go doesn't use GitHub as a package manager. It's just one of the many supported code hosts. In fact, anything that can serve a VCS repo or a zip file is supported.)

This article has nothing to do with the Bluesky lexicon or with the bsky.app AppView.

What does “they will block you” even mean: this article is talking about hosting your data on your PDS and presenting it on your domain.

> While the minimum versions specified in go.mod are not necessarily the version of the dependencies used

This has not been true since Go 1.17 with the default -mod=readonly, which is why go.mod is a reliable lockfile.

It's tricky, to the point that I made a little playground to explore it.

https://github.com/FiloSottile/mostly-harmless/tree/main/dep...

The example.com/mod2 go.mod does not in fact affect version resolution, because it's not even fetched. However, it affects the example.com/mod1 go.mod, and the example.com/mod1 go.mod affects version resolution.

This doesn't help with the problem you are describing, but it still has value from a security point of view, because example.com/mod2 truly doesn't matter except to the extent that was already checked into example.com/mod1, which you do need to trust.

If you try to "go build" or "go test" something in example.com/mod2, you actually do get an error since Go 1.17, as if it was not in your dependency tree at all. You need to "go get" it like any new dependency.

No.

As explained in the post, if a transitive dependency asks for a later version than you have in go.mod, that’s an error if -mod is readonly (the default for non-get non-tidy commands).

I encourage you to experiment with it!

This is exactly how the “stricter” commands of other package managers work with lockfiles.

If that PR were merged, whoami.filippo.io would still work the same. It would just receive signed requests instead of queries.

Frank does great work that is critical to many businesses, and should get funded to do it professionally.

However, donating money to an open collective is prohibitively hard for most big companies. Maybe the world should be different (or maybe not, since it would be easy for employees to embezzle money if they could direct donations easily), but that's how it works currently.

AFAICT, there is also no fiscal sponsor, so the donation matching suggested in a sister comment won't apply.

This is why Geomys (https://geomys.org) works the way it does, and why it has revenue (ignoring the FIPS and tlog sides of the business) which is 30-50x of some GitHub Sponsors "success stories": we bill in a way that's compatible with how companies do business, even if effectively we provide a similar service (which is 95% focused on upstream maintenance, not customer support).

I am not saying it's for everyone, or that Frank should necessarily adopt this model, or that it's the only way (e.g. the Zig foundation raises real amounts of money, too), but I find it frustrating to see over and over again the same conversation:

- "Alice does important maintenance work, she should get professionally funded for it!"

- "How does Alice accept/request funding?"

- "Monthly credit card transactions anchored at $100/mo that are labeled donations"

- no business can move professional amounts of money that way

- "Businesses are so short-sighted, it's a tragedy of the commons!"

Browser vendors have absolutely thought about this, at length.

The web platform is intricate, legacy, and critical. Websites by and large can’t and don’t break with browser updates, which makes all of these things like operating on the engine in flight.

For example, click through some of the multiple iterations of the Schemeful Same Site proposal linked from my blog.

Thing is, SameSite’s primary goal was not CSRF prevention, it was privacy. CSRF is what Fetch metadata is for.

It's why I like Sec-Fetch-Site: the #1 risk is for the developer to make a mistake trying to configure something more complex. Sec-Fetch-Site delegates the complexity to the browser.

See the same-site section of https://words.filippo.io/csrf/

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

You don’t, but remember you monitor your own keys: if you know you didn’t upload a poisoned key and the log refuses to serve a key preimage for your email, you’ve caught it misbehaving.

Fixed (1) in https://github.com/FiloSottile/torchwood/commit/8b61ef967, thank you!

I'll add a note to the part of the article that mentions non-majority policies.

No, the point of the Merkle tree inclusion proofs and of the witness cosignatures is precisely that the operator can't show a different view of the log to different parties.

The SKS network is append-only in aspiration. There is nothing like a Merkle tree stopping a server in the pool (or a MitM) from serving a fake key to a client. The whole point of tlogs is holding systems like that accountable. Also, the section on VRFs of the article addresses precisely the user removal issue.

Honestly not sure why I didn't do that once the tool had stabilized.

Switched to

    go install filippo.io/torchwood/cmd/age-keylookup@main
    age -r $(age-keylookup alice@example.com)

age is designed to be composable and very stable, and this shell combination works well enough, so it's unlikely we'll build it straight into age(1).

>:)

I am a CT log operator and I hands down support short-lived certificates. Automation and short lifetimes solve a lot of the pain points of the WebPKI.

We can solve the storage requirements, it’s fine.

Ignoring the damaging and self-serving behavior of Bernstein for a moment, and focusing only on the technical claim at the core of the conspiracy theory: it makes absolutely no sense.

The assertion is that the NSA is subverting standards processes to push pure ML-KEM key exchanges, the same algorithm they are requiring for their own TS//SCI information in CNSA 2.0.

There is mathematically no place for a NOBUS backdoor in ML-KEM (see https://keymaterial.net/2025/11/27/ml-kem-mythbusting/), so the assertion is that the NSA wants the US Government to use broken cryptography for its most sensitive information. Broken in the sense that an adversary or academic could discover how to break it tomorrow (or yesterday), throwing the government signals handling in disarray, or silently causing a counter-intelligence catastrophe.

That's... ridiculous? Bernstein wraps this in a lot of words and emotionally charged gish gallop, but the core technical point doesn't hold. And it's getting tiresome, and getting in the way of actually important PQ rollout work.

Before anyone claims there's precedent: there isn't. Dual_EC_DRBG was a NOBUS backdoor (and anyway was not authorized for TS//SCI as part of Suite B, the predecessor of CNSA 2.0), and export ciphers were for everyone else not for USG data.

There are definitely better cryptographers than me working at Zcash, for example.

A cloud service that lets users upload their certificates and private keys, to be served by the service's CDN. Here the attacker is attacking the system's availability, not the key.

(But also, it's easy to see how this is a problem for public keys and ciphertexts, and it would be weird to have an inconsistent API for private keys.)

I'm not sure what you are referring to, but we were talking about keys, not IVs.

Also, "an unambiguous key type that can be constructed from a []byte or responsibly generated on your behalf" is exactly what crypto/mlkem exposes.