Developer tools · SHA hash calculator
A Matching Checksum Is Not a Signature: Integrity vs Authenticity
· Why it matters
sha-256 cryptography security
A published SHA-256 lets users detect a corrupted download, but if the attacker controls the page they control the checksum too. This post separates integrity from authenticity and explains what signatures add.
The checksum on the same page as the download — why it protects against corruption but not against a compromised host
A software release is published with a SHA-256 checksum on the same page as the download. Users can fetch the archive, hash it, and compare the result to the published value. If they match, the download is not corrupted. This is integrity verification, and it is a real and useful check. However, if an attacker compromises the web server hosting the release, they can replace the binary, recompute its SHA-256, and update the checksum on the page. The user verifies the checksum and the attacker's malware appears to come from the publisher. The system worked exactly as designed, but it failed to answer the question the user thought they were asking.
This is not a failure of the checksum itself. It is a correct observation about what a checksum does and does not do. A checksum proves that two copies of data are identical. It does not prove who created the data. That is the distinction between integrity and authenticity, and conflating them is one of the most common security mistakes in release verification. Many systems are broken not because their checksums are wrong, but because users trust them to answer questions they cannot answer.
What a hash proves — that two inputs are the same bytes, and nothing about who produced them
Integrity is a property of the data itself. If you have a file and its SHA-256, and the file has not been modified, the hash matches. The hash proves that every byte is unchanged from when it was computed. If the file was corrupted by a transmission error, a disk failure, or a flipped bit on a network cable, the hash will not match. This is what checksums do well. They are excellent at catching accidents and random corruption. They fail against an adversary who can also compute hashes.
Authenticity is a property of the claim about who produced the data. The question "did this file come from the publisher I trust?" is fundamentally different from the question "has this file been modified?" A hash by itself cannot answer the authenticity question because anyone can compute a hash. The attacker who modifies the file can compute the new hash and post it just as easily as the legitimate publisher could. Hashing is symmetric; both the defender and the attacker have the same computational ability.
The trusted-channel requirement — why a checksum is only as trustworthy as where you got it
The trusted-channel requirement is the key insight. A checksum is only as trustworthy as the channel it came through. If you download the software binary from the publisher's official CDN and download the checksum from the same server, they traveled the same path. Compromising the server means an attacker controls both. The checksum provides defense against corruption during delivery—a damaged file will not match—but not against an attacker who controls the source. The checksum and the file share a single point of failure.
If the checksum were published separately, on a different server, with different access controls, then it provides more defense. An attacker who compromises the primary site would need to compromise both locations to fake a matching pair. This is better, but it still relies on two independent control points remaining secure. The attacker must now breach two systems instead of one, raising the cost of the attack. But it is still not proof of authenticity; it is just a more expensive attack.
Signatures bind a hash to an identity — how signing the digest with a private key adds authenticity
A digital signature addresses this by binding the data to an identity using cryptography. The publisher generates a keypair: a private key they keep secret and a public key they publish. They sign the file by computing a digest and then encrypting that digest with their private key. The result is the signature. A user verifies the signature by decrypting it with the publisher's public key and checking that the result matches the computed digest of the received file. The cryptography creates an asymmetry the checksum cannot achieve.
If this works, two things are proven: the data matches the digest the publisher signed, and the private key used to sign it matches the published public key. That proves the publisher created it, not just that an attacker did. The public key must come through a secure channel—usually a certificate from a trusted certificate authority—but once you have the public key, you can verify signatures from that publisher indefinitely. The attack now requires stealing the private key, which is far harder than compromising a web server.
Worked example — three threat scenarios (corrupt mirror, compromised page, malicious insider) and what checksum and signature each catch
Three threat scenarios illustrate the difference. Scenario one: the download mirror is corrupted by a random error. The checksum catches it; the signature catches it. Both work equally well because neither needs to defeat an attacker. Scenario two: the mirror is compromised by an attacker who replaces the file and the checksum. The checksum fails to protect; the signature still works, because the attacker does not have the private key and cannot forge a valid signature. The attacker can post anything, but the signature proves it is not from the publisher.
Scenario three: the CDN is compromised but the signature was published through a different channel. The checksum on the CDN cannot be trusted, but verifying the signature still works, because the integrity check is cryptographically tied to the publisher's key, not to the channel. The attacker must now forge a signature, which requires the private key. The signature is the only verification that survives server compromise. This is why signatures are necessary for authenticity; they are the only tool that proves identity despite channel compromise.
TLS's role and its limits — transport security protects the download in flight, not the publisher's server
Transport security protects the connection to the host named by the certificate. It can prevent an observer on the path from substituting download bytes, but it cannot make a compromised publisher origin honest. If that origin serves a modified archive and a freshly computed checksum over valid TLS, both arrive intact and still describe attacker-controlled content.
This is why transport, integrity and authenticity are separate layers. TLS secures a channel, a digest compares bytes and a signature ties a verification result to control of a private key. No layer should be described as proving the property supplied by another, even when a release workflow sensibly combines all three.
What this does not cover — key distribution and trust roots, which are the hard part of signatures
Key distribution is the hard boundary this digest calculator does not cross. A signature verifier still needs an authentic public key or certificate chain and a policy for rotation, revocation and acceptable algorithms. A mathematically valid signature under an untrusted key proves only that the holder of that untrusted key signed the bytes.
Accordingly, the worked scenarios stop where a trusted key is already available. They do not prescribe certificate pinning, public-key infrastructure or release-key ceremonies. Those deployment choices need their own reviewed design; ToolAcre supplies the plain digest that may be signed, not the trust root used to validate an identity.
Takeaway: checksums for integrity, signatures for authenticity — the ToolAcre SHA hash calculator computes digests; verifying who published them is a separate step
The ToolAcre SHA hash calculator computes the integrity side of this verification. Use it to hash the downloaded file and check against a published value. If they match, the download is not corrupted. But if they match because an attacker rewrote both, integrity verification alone will not catch it. The tool is honest about this limitation and does not claim to verify authenticity. For integrity only, checksums are fast and good. For authenticity, you need signatures. TLS provides transport security for the download itself. The connection to the server is encrypted and authenticated, so an attacker on the network cannot modify the file in transit. However, TLS does not help if the server itself is compromised. A compromised server can serve any file over any secure TLS connection. This is why application-level verification—checksums and signatures—matters separately from transport security.
A common pattern in software releases is to publish both checksums and signatures. Checksums are convenient; users can verify them quickly with a one-line shell command. Signatures provide authenticity for users who have the publisher's public key. A user might check the checksum first for a quick integrity pass, and then verify the signature against a key stored in their GPG keyring for authenticity. The two checks serve different purposes and can be layered for defense in depth. The hard part of signatures is key distribution and trust. You need the publisher's public key, and you need to trust that it is really theirs. This is the problem certificate authorities exist to solve: they sign publisher certificates, and the root CA certificates come preloaded in browsers and operating systems. For a smaller project, you might publish a GPG key on a separate, hardened website or on a public key server. The checksum is cheap to verify; signatures require managing trust roots. The additional complexity is the price of authenticity.