How Digital Signatures Work — Proving Authorship and Integrity
Encryption hides data. Hashing verifies integrity. A digital signature does both: it proves who created a message (authentication) and that the message wasn't modified after signing (integrity).
The mechanism: hash the message, then encrypt the hash with your private key. Anyone with your public key can decrypt the hash and compare it to their own hash of the message. If they match: the message is authentic and unmodified.
How Does Signing Work?
Signing:
- Compute the hash of the message (e.g., SHA-256).
- Encrypt the hash with the signer's private key. This encrypted hash is the signature.
- Send the message and the signature together.
Verification:
- Compute the hash of the received message.
- Decrypt the signature with the signer's public key to recover the original hash.
- Compare. If they match, the message is authentic and unmodified.
If anyone changes even one bit of the message, the hash changes, and the comparison fails. If anyone tries to forge a signature, they'd need the private key — which only the signer has.
Which Signature Algorithms Are Used?
Ed25519 — the modern default. Based on the Edwards curve (Curve25519). Fast, small signatures (64 bytes), small keys (32 bytes). Used by SSH, WireGuard, Signal, and many modern systems.
ECDSA — Elliptic Curve Digital Signature Algorithm. Older than Ed25519, more complex, used in Bitcoin and many TLS certificates. Being replaced by Ed25519 where possible.
RSA signatures — the original. Still used in many certificates and legacy systems. Larger keys and signatures than ECC alternatives. RSA-2048 is the minimum acceptable key size.
| Algorithm | Key size | Signature size | Speed | Used in |
|---|---|---|---|---|
| Ed25519 | 32 bytes | 64 bytes | Fast | SSH, WireGuard, Signal |
| ECDSA P-256 | 32 bytes | 64 bytes | Moderate | TLS, Bitcoin |
| RSA-2048 | 256 bytes | 256 bytes | Slower | Legacy TLS, email, code signing |
Where Are Digital Signatures Used?
TLS certificates — the most important use. A Certificate Authority signs a certificate binding a domain name to a public key. Your browser verifies the signature to trust the connection. The entire HTTPS ecosystem depends on digital signatures.
JWTs (JSON Web Tokens) — an authentication token signed by the server. The token contains claims (user ID, roles, expiration) and a signature. Any service with the server's public key can verify the token without contacting the server. JWTs are stateless authentication.
header.payload.signature
eyJhbGciOiJFZDI1NTE5In0.eyJ1c2VyX2lkIjoiMTIzIn0.Kf9gY...
The signature covers the header and payload. If anyone modifies the payload (changing user_id from "123" to "456"), the signature is invalid. If the secret key is used (HMAC variant), only the server can create valid tokens.
Git commits — git commit -S signs the commit with your GPG or SSH key. GitHub shows a "Verified" badge. This proves the commit was created by the claimed author, not someone who gained access to the repository.
Code signing — executables, drivers, and apps are signed by their developers. macOS won't run unsigned apps from the internet. Windows warns on unsigned executables. Android APKs must be signed. The signature proves the code hasn't been tampered with since the developer built it.
Package managers — Debian packages are signed with the repository's GPG key. apt verifies before installing. npm, cargo, and pip have varying levels of package signing.
Blockchains — every transaction is signed with the sender's private key. The network verifies the signature with the public key (the wallet address). No central authority needed — the math proves ownership.
Email (S/MIME, DKIM) — DKIM signs outgoing email headers with the domain's private key. The receiving server verifies with the domain's public key (published in DNS). This prevents email spoofing.
What Is the Difference Between Signing and Encrypting?
| Encryption | Signature | |
|---|---|---|
| Purpose | Hide the content | Prove the author |
| Who uses which key | Sender encrypts with public key | Signer signs with private key |
| Who can do it | Anyone (public key is public) | Only the key owner |
| Who can read/verify | Only private key holder | Anyone (public key is public) |
| Provides | Confidentiality | Authentication + integrity |
A message can be both signed and encrypted. Sign first (with your private key), then encrypt (with the recipient's public key). The recipient decrypts (with their private key), then verifies your signature (with your public key). Now the content is secret AND authenticated.
What Happens If the Private Key Is Compromised?
All signatures made with that key become suspect. An attacker could forge signatures that appear to come from the legitimate signer. The response:
- Revoke the key — publish a revocation (CRL, OCSP for certificates; revocation certificate for PGP).
- Reissue — get a new key pair and new certificates.
- Investigate — determine what was signed during the compromised period.
- Rotate — short-lived certificates (90 days with Let's Encrypt) limit the damage window.
This is why key protection matters. Hardware Security Modules (HSMs) store private keys in tamper-resistant hardware. Certificate Authorities keep their root keys in offline HSMs inside vaults.
Next Steps
- How Key Exchange Works — how two parties agree on a shared secret using asymmetric primitives.
- How Certificates Work — how signatures enable the certificate chain of trust.
- How TLS Works — how the handshake uses signatures for authentication.