Digital Signatures Explained: What They Prove About a File

You download an installer and see a publisher name. Elsewhere, a project offers a separate signature file alongside its release. Both are ways of answering an important question: did this material come from the signer you expected, without changes to the content that was signed?

A digital signature is a cryptographic proof tied to data and a signing key. Proper verification can detect changes and connect the signed material to a trusted identity. It cannot decide whether the software is useful, the document is truthful, or the signer has good intentions.

Understanding that boundary makes signatures more useful than a reassuring badge.

A private key signs; a public key verifies

A signing system uses a pair of mathematically related keys. The private key creates signatures and must be protected. The public key allows other people or systems to check them.

With suitable algorithms and key sizes, knowing the public key does not let someone feasibly calculate the private key or sign a different file on its behalf. This permits public verification without distributing the signing secret.

The same broad arrangement appears in passkey authentication. A passkey signs a fresh login challenge; a file-signing system signs material associated with a particular release or document. The applications differ, but both avoid sharing the private key with the verifier.

A signature may be embedded inside a supported file format or delivered separately as a detached signature. Neither arrangement is inherently more authoritative. What matters is what was signed, which key signed it, and how the verifier establishes trust.

What happens when a file is signed

A simplified workflow has four stages:

1. The signing software identifies the content covered by the signature format.
2. A cryptographic hash function produces a compact digest of that content.
3. The signature algorithm uses the private key to create a signature tied to the digest.
4. The recipient's software checks the signature against the protected content using the corresponding public key.

The exact processing depends on the algorithm and file format. Describing every signature as simply encrypting a file with a private key is misleading; signing and encryption are distinct operations.

If covered content changes, verification of the original signature should fail. An attacker who replaces an installer cannot just copy its old signature onto the altered content and preserve a valid result.

The illustration uses a chipped tile as a metaphor for detectable change. Real verification examines data, not visible damage. A file can look identical on screen while its protected content differs underneath.

A checksum answers a narrower question

A download page may publish a SHA-256 checksum. You calculate your downloaded file's digest and compare it with the expected value. A match is strong evidence that the bytes agree with the reference, assuming an appropriate hash function.

That is useful for detecting corruption or an unexpected file. But the checksum alone does not authenticate whoever published it. Anyone can calculate a new checksum for a replacement file.

If an attacker controls both the download and the page listing its checksum, they can replace both. The comparison will succeed while telling you nothing reliable about the original publisher.

A digital signature adds the signing key to the relationship. Replacing the file and producing a matching signature requires access to the appropriate private key, or a failure elsewhere in the system. Publishers can also sign a checksum list, authenticating the reference values for several downloads together.

The distinction is practical: a hash checks agreement with a reference; a signature can authenticate that reference when you trust the signing key.

A valid signature still needs the right identity

Suppose a hypothetical project publishes a release signed with a key you have never encountered. Verification succeeds mathematically. You now know the file matches that key's signature, but you have not established that the key belongs to the project.

An attacker can generate a perfectly functional key pair and choose a familiar display name. The name alone does not create the identity connection.

Different systems establish that connection differently. OpenPGP workflows can use a public key's full fingerprint checked against an established, trusted reference. Certificate-based systems connect a signing key to an identity through an issuer and a chain leading to a trusted root.

The chain illustration represents this dependence on an anchor. Accepting a new key or certificate merely because it arrived beside a download does not establish independent trust.

For automated verification, the expected identity must be explicit. Sigstore's verification documentation, for example, requires checking the expected certificate identity and identity issuer for its identity-based workflow. A check that accepts any signer misses the question of whether this is the signer you intended.

Signing does not make a file secret

A signed document can remain completely readable. The signature protects the ability to detect changes and verify origin; it does not itself restrict who can see the content.

Our end-to-end encryption explainer covers a different promise: limiting readable access to the intended endpoints. A system can combine signing and encryption, but one should not be assumed from the other.

Nor does a valid signature prove that content is recent. An old, correctly signed release may still verify even when a newer version fixes serious vulnerabilities. Preventing unwanted rollback requires a separate policy about acceptable versions or freshness.

Signed software can still be dangerous

A signature authenticates material produced through a signing process. It does not inspect every instruction in a program or certify every dependency.

A legitimate developer can release software with a serious bug. A malicious publisher can sign harmful code. An attacker who compromises a build pipeline might insert unwanted behavior before the legitimate signing step. Someone who obtains access to a signing key or service may produce unauthorized signatures.

These are different failures from changing a file after it was signed. In its software supply chain guidance, CISA and partner agencies describe how a compromised artifact can receive a valid signature when the build or signing process is compromised.

That makes signing one layer in a broader system of release controls, protected credentials, review, and monitoring. It also explains why a signature check should not suppress other security warnings or justify unnecessary administrative access.

Expiry and timestamps require context

Signing certificates commonly have validity periods. A verifier may also check revocation information, allowed uses, algorithms, and the trust rules of its platform.

A trusted timestamp can provide evidence that a signature existed at a particular time. Microsoft's Authenticode system uses timestamps to support verification after the signing certificate expires, subject to the applicable validation rules.

This is different from a date typed into a document or a file's modification time. Those values do not independently prove when the signature was created.

An expired certificate therefore needs interpretation within the signing system. Conversely, a timestamp cannot make a malicious release safe or erase every reason a certificate might be distrusted. Use the platform's verification result and the publisher's guidance rather than overriding a warning based on one displayed date.

A practical check before you open or install

You do not need to become a cryptographer to use signatures well:

1. Establish the source first. Reach the publisher through an address or distribution channel you already trust. A familiar name in a search advertisement is insufficient.
2. Use the supported verifier. Follow the project's instructions or the operating system's built-in verification workflow for that file format. A signature file merely being present proves nothing.
3. Check the expected signer. Compare the publisher identity, full key fingerprint, or documented workflow identity as appropriate. Investigate an unexpected change before proceeding.
4. Read the complete result. Distinguish a matching signature from an unknown identity, untrusted chain, expired credential, or other validation problem.
5. Check the release itself. Confirm the intended version, platform, and update status. A genuine old file may be unsuitable today.
6. Keep the wider decision intact. Consider requested permissions and other security findings. Verify unexpected instructions through an established channel.

This follows the broader zero trust habit of checking access and assumptions. Evidence of origin should inform a decision, not replace every other check.

The useful question is precise: does this protected content match a signature from the identity I intended to trust? Answering it removes an important uncertainty while leaving the file's safety, purpose, and permissions open to proper review.