OpenPGP signing keys have similar problems. Web of Trust is useless if you don't know any developers to begin with, dates on public keys can be forged, and false signatures can be forged by creating a large number of other false keys. False keys can be made more misleading using 32-bit short Key ID collision (and don't blame OpenPGP for this, OpenPGP is notorious for its complexity but at least it tried, meanwhile alternative tools like OpenBSD's signify does not attempt to address this problem - these tools of course are simpler).

Surprisingly, I think no attacker has ever forged a OpenPGP signature in a real-world security incident, likely because there's a lack of overlap between crypto nerds and crackers.

Though, public keys do not change often and leave somewhat of an "audit trail". I usually search the key fingerprint on the web to see if it has been mentioned elsewhere as a quick check. Some projects store signing keys in an official upstream git repository. It's somewhat of a higher guarantee, but one can still creates a false upstream page for phishing... But I guess it's too much of an effort so nobody has tried to do this, yet.

Thankfully, for distro users, it's only something for packagers to worry about, end users always receive verified packaged via the distro package manager.

> Surprisingly, I think no attacker has ever forged a OpenPGP signature in a real-world security incident, likely because there's a lack of overlap between crypto nerds and crackers.

I suspect in the real world almost nobody validates PGP keys of software downloads manually. They might do it automatically (for example via a Linux package manager), which a fake key wouldn't fool. Thus, faking the key isn't necessary because 99% of users that could be fooled won't bother checking.

The 1% that do verify it would report the issue and alert others.

The big advantage of an OpenPGP signature over a checksum/hash is that you only have to verify the identity once. The identity can be used to verify the signatures of an unlimited number of files. That is as opposed to requiring each file to have a separate checksum/hash. Much more opportunity for deception on the smaller scale.

A perhaps less appreciated advantage is that in practice the identities are stored offline with each entity that will be verifying the signatures. So an attacker has to justify the use of the new identity to what would normally be a large number of entities. That might explain why that sort of attack is so rare.

Efficiency on scale instead of detail.

A hash method would quickly run out of disk space before it could be used to verify every single file. Hence hashed b-tree for xfs (or is it jfs? I forget), and stuff like that.

A verify once used many times method is more efficient on a large scale.

I'm no maths expert, heck i don't even know calculus.

Put the checksums in a separate system such as the DNS. Use DNSSEC on your domains. Manage your DNS system as an isolated system (don't mix your HTTP/Email/Other stuff with your DNS provider). Now, users may verify the downloads you provide at your website by getting checksums from the DNS.

DANE may be of interest here as well:

https://www.infoblox.com/dns-security-resource-center/dns-se...

Is there any tooling around this?

In particular, it's crazy that I can't just stick a public key for my email address in the DNS record for my domain, and have email auto E2E encrypt to it.

(No, that wouldn't scale for gmail, but they could do a two level thing, where the gmail key signs the public key for each mailbox -- assuming people bothered to set up their own keys, or that gmail just silently opted them in to server side encryption.)

How does DNSSEC help here at all? We're talking about the security of checksums of data on pages. DNSSEC only addresses the name lookup.

That just makes DNS the single point of failure. If you own DNS, you can change the checksum and the download all at once.

Checksums are meant to verify data integrity. Who ever said otherwise?

It doesn't matter, people still use checksums as a signal to verify if a download has been tampered with

> it'd be trivial for a bad actor to change them if the files are compromised.

But it's trivial for responsible members of an organization to set-up a continuous, automated verification of the checksums listed on a web page. It wouldn't be practical to do that with the ISOs, directly.

Of course if the organization is lazy or incompetent, and chooses not to do so, then they have only themselves to blame. But if you fail to compare your downloaded files to the listed checksums, that's all on you.

> I don't really have a solid solution to this

My solution to this when designing Homebrew’s binary packages was to store the checksums for the binaries in Git but the binaries themselves elsewhere (inspired by Homebrew already storing source checksums in Git).

On Homebrew, therefore, you’d have to compromise both the binaries and the Git repository.

These are both nowadays on GitHub but the binaries in GitHub Packages are addressed by their checksum and the Git repository has a good audit log.