Notes on Signatures
How to ensure origin and integrity of a message?
Encryption, whether Symmetric Encryption or Asymmetric Encryption, answers a single question: can anyone else read this? It stays silent about everything else. When Bob receives the message "meet me at noon", how does he know it truly came from us rather than from Eve typing the same words? And how does he know nobody adjusted the time along the way? Secrecy turns out to be only half of the story; the other half is authenticity, and that is what the digital signature provides. It is Asymmetric Encryption played in reverse: instead of locking with the recipient’s public key, we lock with our own private one, trading confidentiality for proof.
Locking a message with our own private key sounds absurd as a way of keeping secrets (everyone holds our public key, so anyone can unlock it), yet that absurdity is precisely the point: if the message unlocks cleanly with our public key, only our private key can have locked it, and we are supposed to be its sole owner.
signing: document + sender's private key → signatureverification: document + signature + public key → valid or invalidOne refinement makes it practical: documents can be huge, so we never sign the document itself, only its Hashing fingerprint. The signature then travels alongside the original, and verification recomputes the hash before checking anything. Due to the nature of hash functions, any single character flipped along the way produces a different fingerprint and it becomes evident that the contents have been tampered with.
In short, a valid signature gives us three guarantees at once: origin (the private key holder signed it), integrity (nothing changed afterwards) and even non-repudiation (the signer cannot plausibly deny it later).
- RSA-PSS: runs on the same RSA machinery as encryption;
- ECDSA: elliptic-curve signatures with a small footprint; common in TLS certificates and Bitcoin;
- Ed25519: the modern favourite, fast, compact and famously hard to misuse.
Let’s sign our message and watch verification succeed, then fail:
echo "meet me at noon" > message.txt
openssl dgst -sha256 -sign my_private.pem \ -out message.sig message.txt# No output; message.sig holds the signature
openssl dgst -sha256 -verify my_public.pem \ -signature message.sig message.txt# Verified OKAll good so far. Now suppose Eve appends a clever request to our message without touching the signature:
echo "bring snacks" >> message.txt
openssl dgst -sha256 -verify my_public.pem \ -signature message.sig message.txt# Verification failureThe check fails outright, because the fingerprint underneath the signature no longer matches. Note also that message.sig stays the same size regardless of what we sign: it covers a hash, not the document.
A valid signature proves that the holder of a particular private key signed the document; it says nothing about which human that holder happens to be. Eve can happily sign her own forgeries with her own perfectly valid key, and every check passes. Binding keys to identities is a separate problem, solved by Certificates (which are themselves just signed statements).
The private key needs to be securely stored: a stolen signing key produces forgeries indistinguishable from our own work.