The previous piece on this site described content addressing: a hash of a thing's bytes becomes its address, and a matching hash proves you received exactly the bytes the address describes. That piece closed on a boundary worth reopening on its own, because it's the kind of distinction that's easy to state and easy to forget under pressure — verifying that content is intact and verifying that content is trustworthy are different problems, solved by different mechanisms, and a hash by itself only ever solves the first. This piece is about what separates a checksum from a signature, and why the gap between them is not a technical nuance but the entire reason both exist.
The oldest form of this idea predates cryptography entirely. A parity bit, a CRC, an old-fashioned checksum on a downloaded file — all of these compute some small, fast summary of a block of data and attach it, so that a receiver can recompute the same summary and compare. What they're built to catch is accidental corruption: a scratched disk sector, a flipped bit from electrical noise on a wire, a truncated download. They're cheap to compute precisely because they don't need to resist a determined adversary — nothing about a CRC makes it hard to find a different block of data that produces the same checksum on purpose. That's not a flaw in the design; it's simply outside the problem the design was built for. A checksum answers "did this arrive the way it left," assuming nothing between the two ends was trying to make it look that way while actually changing it.
A cryptographic hash function — the kind content addressing relies on — is a stronger tool built for a related but distinct purpose. It's designed so that finding two different inputs that produce the same output is computationally infeasible, not just unlikely by chance. That property, collision resistance, is what makes a cryptographic hash usable where a CRC isn't: it can catch deliberate tampering, not just accidental noise, because an attacker who changes the content can't cheaply engineer the hash to still match. But this is where the distinction the previous piece flagged and moved past deserves to be sat with longer. A hash catching tampering assumes the verifier learned the correct hash through some channel the attacker didn't also control. If someone can intercept a file in transit, they can just as easily intercept the hash published alongside it and substitute both. The hash doesn't defend that channel; it only makes the channel's trustworthiness the entire question. This is the seam a checksum and a cryptographic hash share, no matter how strong the hash function underneath: both require the verifier to already trust wherever the expected value came from, and neither one does anything to establish that trust on its own.
A digital signature is built specifically to remove that requirement. It uses a key pair — a private key kept secret by the signer, and a public key anyone can hold openly — with a mathematical relationship between the two such that a signature produced with the private key can be verified with the public key, but the public key alone gives no practical way to produce a valid signature. In practice, the signer hashes the content (the same kind of hash as before, doing the same integrity job it always did) and then encrypts or otherwise transforms that hash using the private key. Anyone with the public key can reverse that transformation, recover the hash, hash the content themselves, and check the two match. If they do, two separate things are now established at once: the content wasn't altered after signing (the hash-matching part, same guarantee content addressing gives), and whoever produced this signature held the specific private key that corresponds to this specific public key (the part a bare hash could never provide).
The genuinely useful move here is where the trust requirement got relocated, not removed. A signature doesn't let you skip trusting something — it lets you trust a much smaller, more durable thing: one public key, established once, rather than every individual message or file that key ever signs afterward. The file and its signature can travel over the least trustworthy channel imaginable — a public download mirror, an unencrypted connection, a USB drive handed around a conference — because tampering with either the content or the signature breaks the match, and forging a new matching signature requires the private key, which never had to leave the signer's control. The one thing that still needs a trustworthy channel, at some point, is the public key itself: if an attacker can convince you their public key is the legitimate signer's, they can sign anything they want and you'll verify it successfully. That's not a loophole in the scheme; it's the specific, narrowed problem the whole apparatus of certificate authorities, key-signing parties, and trust-on-first-use key pinning exists to manage. Signatures don't eliminate the need for a trusted channel — they shrink it from "every file, every time" down to "one key, once," which is a problem worth having instead.
It's worth being as exact about a signature's limits as the previous piece was about a hash's, because the two failure modes people fall into are mirror images of each other. With a bare hash, the mistake is crediting it with authenticity it never claimed. With a signature, the mistake runs the other way: crediting it with correctness or trustworthiness of the content itself, when all it actually attests to is which key signed it. A legitimate developer's private key can sign a build with a real bug in it, or software that behaves exactly as intended and is still malicious by design, and the signature will verify perfectly — because it was never a claim about the content being good, only a claim about who vouched for it. Verifying a signature answers "did the party I already trust actually produce this," which is only as useful as the trust you'd already extended to that party for other reasons.
Two further limits are easy to lose sight of. A signature says nothing about timing unless something else — a separate timestamp, a transparency log, a trusted timestamping authority — is added on top; by itself it doesn't distinguish a signature made an hour ago from one made three years ago, before the signer's key was later compromised. And a signature is only as good as the secrecy of the private key behind it: the moment that key leaks, every future signature made with it (and, depending on the scheme, potentially every past one whose timing can't be independently proven) is suspect, which is why key revocation and rotation are load-bearing parts of any real signing system, not optional hygiene. The mathematics of the signature never weakens; what breaks is always the boundary around the key, the same way a lock's strength was never the question once someone else has a copy of the key.
Stated at its narrowest: a checksum tells you the bytes are the bytes you expected. A signature tells you a specific key attested to those bytes. Neither one tells you the bytes deserve to be trusted — that judgment still has to come from somewhere outside the cryptography, applied once, to the much smaller question of whether a given key is one you should believe in the first place.