What a signature proves
A handwritten signature is meant to show who agreed to a document. A digital signature does a stricter job for data. NIST’s Digital Signature Standard, FIPS 186-5, says signatures are used to detect unauthorised changes to data and to authenticate the identity of the signatory. It adds a third property: the recipient can show the signature to someone else as evidence that the claimed signatory produced it. This is called non-repudiation, because the signer cannot easily deny it later.
Signatures work on stored data, such as a software update or a document, and on data in transit, such as a message crossing a network. If the data has changed since it was signed, verification fails.
How signing and verifying work
Every signer has a key pair: a private key that must stay secret and a public key that can be shared with anyone. Public and private keys covers the idea in more depth.
- Signing. The signer runs a signature algorithm over the data with the private key. For RSA and ECDSA, the data is first condensed by a hash function into a fixed-length message digest, and the algorithm signs that digest. EdDSA works on the message itself.
- Sending. The signature is sent or stored alongside the data. The data is not hidden.
- Verifying. The verifier runs the matching verification algorithm with the signer’s public key, the data, and the signature. The result is valid or invalid.
FIPS 186-5 states that only the holder of the private key can generate a signature, and that the approved algorithms are designed so that someone without that key cannot produce a valid signature on a different message. In other words, a signature cannot be forged without the private key.
The algorithms in use
FIPS 186-5 approves three families of signature algorithm:
- RSA, specified in RFC 8017.
- ECDSA, the elliptic curve algorithm, including a deterministic variant from RFC 6979.
- EdDSA, the Edwards-curve algorithm specified in RFC 8032, which includes Ed25519 and Ed448.
The older DSA is no longer specified and may only be used to verify signatures made in the past. RFC 8032 lists the practical appeal of EdDSA: it is fast on many platforms, needs no fresh random number for each signature, and uses small keys and signatures. Ed25519 public keys are 32 bytes and its signatures are 64 bytes. How Ed25519 signatures work walks through the algorithm step by step.
RFC 8032 also notes that a sufficiently large quantum computer could break both Ed25519 and Ed448. NIST has since published FIPS 204, which specifies ML-DSA, a signature scheme it describes as believed to be secure even against an adversary with a large-scale quantum computer.
Signatures, MACs, and encryption
Three tools are often confused:
| Tool | Key | What it gives |
|---|---|---|
| Digital signature | Private key signs, public key verifies | Integrity, proof of origin, and evidence a third party can check |
| Message authentication code (MAC) | One secret key shared by both sides | Integrity and proof of origin, between the parties holding the key |
| Encryption | Depends on the scheme | Confidentiality: only key holders can read the content |
NIST SP 800-57 explains the difference between the first two. A MAC uses a symmetric key that the parties share, and it authenticates the source only if that key is unique to each pair of parties. A signature uses a key only the signer holds, so anyone with the public key can verify it, and it can support a non-repudiation decision.
Neither a signature nor a MAC makes content private. That is the job of encryption, and in a messaging app usually of end-to-end encryption. Offline Protocol’s documentation gives a concrete case of the difference: in its SDK, service advertisements, requests, and responses are signed plaintext, so they are attributable and tamper-evident but readable by anyone who observes them, while application messages are encrypted with MLS.
What a signature does not tell you
A valid signature proves less than it may seem.
- Whose key it is. Verification shows that the holder of a particular private key signed the data. FIPS 186-5 points out that a verifier also needs assurance that the claimed signatory really owns that key pair; otherwise anyone with a key pair could sign a message and claim to be someone else. Certificates from a public key infrastructure are one way to bind a key to an identity. Trust on first use and identifiers derived from the public key itself are others.
- When it was signed. NIST SP 800-102 notes that a signing time written inside a message gives no assurance unless that time can be trusted. It describes trusted timestamps and data supplied by the verifier, such as a fresh challenge, being included in what is signed. Without something like that, an old signed message can be presented again and still verify.
- Whether the key is still safe. FIPS 186-5 says the security of a signature system depends on keeping the signatory’s private key secret. A stolen key produces valid signatures until verifiers learn to stop trusting it.