Digital Signatures
Prove who wrote it — and that no one changed it.
What it does
A digital signature answers a question the other tools can't: who produced this, and has anyone altered it since? It is not secrecy. A signed message stays fully readable — the signature travels alongside it as a separate proof.
Think of it as the mirror image of encryption. Encryption hides a message so only the right person can read it. A signature leaves the message in the open but makes it so only the right person could have written it. Same key machinery, opposite goal: confidentiality versus authenticity.
The public-key flip
On the encryption page you met the split between symmetric keys (one shared secret) and asymmetric keys (a public/private pair). Signatures live entirely in the asymmetric world — and they use the pair backwards from how encryption does.
- To sign: you use your private key — the one you never share. Only you can produce the signature.
- To verify: anyone uses your public key — the one you hand out freely. They can check the signature but could never have created it.
That asymmetry is the whole trick. Because verifying needs only the public key, you can publish it on a billboard. And because signing needs the private key, a valid signature is something only you could have made — which is also why you can't later deny it. That property has a name: non-repudiation.
You sign the fingerprint, not the message
Public-key math is slow and works on small, fixed-size numbers — not on a 40 MB PDF. So signatures borrow from hashing: you hash the message first, then sign the digest. The signature covers a compact 256-bit fingerprint that stands in for the entire document.
“I authorize the transfer of 100 credits.”
…
3045 0221 00b8 4e… — only the private key could make this
To verify, anyone re-hashes the message and asks the matching public key whether that digest and signature line up. The public key can check a signature but never create one — which is exactly why it's safe to publish.
This is why a signature is tamper-evident for free. Change a single byte of the message and its hash avalanches into a completely different digest — so the old signature, which sealed the old digest, no longer matches. Verification fails, loudly. Signatures are hashing and asymmetric keys working together; that's why this page is built from hashing.
Sign it, then try to break it
Two fresh key pairs are generated below, entirely in your browser. Sign a message, then break the signature two different ways: edit the message after signing, or check it against someone else's public key. Both fail — for different reasons.
…
—
Signature rejected
The message changed after signing, so the signature no longer matches its contents.
You edited the message after signing. Re-sign, or watch the check fail.
A signature is not encryption
The most common mix-up: “it's signed” does not mean “it's secret.” A signed email is still plain text anyone can read — the signature only proves it came from you, unaltered. If you also need it hidden, you encrypt and sign. They're separate jobs that often ride together.
Where you already trust them
- Every HTTPS site— the certificate that proves a server is who it claims is a signed statement. You'll watch that exact check on the TLS page.
- Software updates— your OS and app stores refuse an update whose signature doesn't match the vendor's key, which is what stops a tampered install.
- Git commits & releases — signed tags and commits prove who authored code.
- Tokens & wallets — JWTs carry a signature so a server trusts them without a database lookup; a crypto transaction is a signature authorizing a transfer.
ECDSA, RSA, and why curves won
The demo uses ECDSA — the Elliptic Curve Digital Signature Algorithm — on the P-256 curve. The older RSA does the same job with much larger keys: a 256-bit elliptic-curve key matches the strength of a 3072-bit RSA one. Smaller keys and signatures mean less to send and less to compute, which is why modern protocols lean on curves.