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