You download a software package from the internet. The website tells you it's the official release from the expected publisher. But how do you actually know that? The file could have been modified in transit, or the server could have been compromised, or you could be downloading from a mirror you don't fully trust.
A checksum helps with one part of this. If the publisher posts a SHA-256 hash of the file, you can download the file, compute its hash, and compare. If the hashes match, the file wasn't corrupted or modified after the hash was published.
But there's a problem: the hash itself has the same authenticity problem as the file. If an attacker can replace the file, they can replace the published hash too. A hash tells you whether something changed. It doesn't tell you who computed it.
Digital signatures solve the authenticity half of this problem.
Why Hashing Alone Isn't Enough
A cryptographic hash function takes an arbitrary input and produces a fixed-size digest. Change a single byte in the input and the digest changes completely. That property is useful for detecting modification.
Message
↓
SHA-256
↓
256-bit digest
But anyone who has the message can compute its hash. There's nothing in the hash itself that proves who created it or that it came from a specific source. For that, you need something only one party can produce: a private key.
Signing a Message
The signing process goes like this:
Message
↓
Hash function
↓
Message digest
↓
Private key + signature algorithm
↓
Digital signature
The signer computes a cryptographic hash of the message first. That digest is a compact, fixed-size representation of the message content. Then a signature algorithm uses the signer's private key to produce a signature over that digest.
The reason for hashing before signing is practical: messages can be arbitrarily large, but the digest has a fixed size regardless of input length. The signature algorithm operates on the digest rather than the original message. This is efficient, and because a secure hash function makes it computationally infeasible to find two inputs with the same digest, signing the digest is equivalent to signing the message.
One thing to be precise about: producing a digital signature is not the same as encrypting the message with a private key. That description is a common oversimplification and it's wrong in a way that matters. Digital signatures use signature algorithms designed specifically for this purpose. The output is a signature, not ciphertext, and the process is conceptually different from encryption.
How Verification Works
A verifier has three things: the message, the digital signature, and the signer's public key.
Received message ──→ Hash ──────────────────────┐
▼
Digital signature ──→ Public key ──→ Verification result
The verifier hashes the received message to produce a digest. The signature verification algorithm uses the public key to check whether the signature is valid for that digest. If the message was altered after signing, the digest computed by the verifier won't match what was signed. Verification fails. If the signature was produced by a different private key than the one corresponding to the provided public key, verification fails.
A valid verification result means two things: the message has not been modified since it was signed, and the signature was produced by whoever holds the corresponding private key. The public key can be distributed freely. It cannot be used to derive or reconstruct the private key in a properly designed system.
Integrity and Authenticity Are Separate Properties
A digital signature provides both integrity and authenticity, but they're worth distinguishing.
Integrity means the signed data hasn't changed. A properly designed signature scheme uses a hash function where even a one-bit modification to the message causes verification to fail.
Authenticity means the signature was produced by the holder of a specific private key. This is more subtle than it might seem. A valid signature proves control of a private key. It doesn't automatically prove the real-world identity of the person holding that key. Identity binding requires additional infrastructure.
This Is Not Encryption
Digital signatures are often conflated with encryption, especially in casual descriptions. They're different mechanisms with different goals.
Encryption provides confidentiality: only the intended recipient can read the content. A digital signature provides integrity and authenticity: anyone with the public key can verify that the signature is valid for that message. Signing a message doesn't hide it. If you want both authenticity and confidentiality, you need both signing and encryption, and they're applied separately.
Non-repudiation is sometimes associated with digital signatures: if only one party holds a private key and a valid signature exists under the corresponding public key, it's difficult for that party to deny having signed the message. But non-repudiation as a legal or practical guarantee depends on key control, identity binding, and surrounding evidence. It's a useful property, not an automatic absolute guarantee.
Signature Algorithms in Practice
Three signature schemes are worth knowing by name.
RSA-PSS is a signature scheme based on RSA. Modern RSA signing should use an appropriate padding and signature construction like PSS rather than naive textbook RSA. The underlying RSA key pair supports both signing and encryption, but those are distinct operations.
ECDSA (Elliptic Curve Digital Signature Algorithm) produces signatures using elliptic-curve cryptography. It achieves comparable security to RSA with significantly shorter key lengths.
Ed25519 is a modern elliptic-curve signature scheme built on the Edwards curve. It's fast, produces short signatures, and has a simpler security model than ECDSA. It's widely used in SSH keys, TLS, and secure messaging protocols.
These schemes have different mathematical constructions and different performance characteristics. They don't work identically internally, but they serve the same conceptual purpose.
Knowing Whose Key to Trust
A digital signature proves that a specific private key produced the signature. But knowing that a signature is cryptographically valid doesn't tell you whose key you're trusting.
Certificates solve this by binding a public key to an identity using a signature from a trusted certificate authority. When your browser validates an HTTPS connection, it's checking that the server's public key is certified by a CA your browser trusts. The certificate is itself a signed document: the CA's signature over the server's public key and identity information.
Software signing works similarly. Operating system package managers, code signing for mobile apps, and signed Git commits all rely on some mechanism for trusting a public key in the first place.
Private Key Security
The security of a digital signature scheme depends on the private key remaining private. If an attacker obtains the private key, they can produce signatures that verify successfully under the corresponding public key. The signatures would be cryptographically indistinguishable from legitimate ones.
This is why private keys are protected carefully, stored in hardware security modules, rotated when compromised, and revoked through certificate revocation mechanisms when necessary. The cryptography is sound; the operational security around key management is where things go wrong in practice.
The private key creates a signature over a digest of the message. The public key lets anyone verify that signature against the message. If the message changes, the digest changes, and verification fails. If the signature came from a different private key, verification fails.
That's the entire mechanism. The layers on top, certificates, trust hierarchies, revocation, key management, all exist to answer the question the signature itself can't answer: whose key is this, and should you trust it?
Top comments (0)