Almost everyone assumes that digitally signing means encrypting a message so nobody can read it. It does not. The two are cousins that are often confused: encryption is about secrecy; signing is about what and who. In this article we separate the wheat from the chaff and open up the engine behind digital signatures: asymmetric keys, hash functions, and two concrete pieces of mathematics called RSA and ECDSA.
The problem signing solves
When you receive a message you need answers to three questions that encryption alone cannot provide:
- Is it intact? Nobody altered it along the way.
- Is it authentic? It really comes from whoever claims to have sent it.
- Is it non-repudiable? The author cannot deny it afterwards.
That is exactly where the digital signature steps in: a mathematical attachment to the message that certifies all three properties at once.
The key pair: public and private keys
Signing relies on asymmetric cryptography, which uses two mathematically linked keys: a private one, known only to its owner, and a public one that can be printed on a poster. Picture the private key as a and the public one as A: you can derive A from a, but the reverse step is so expensive to compute that it becomes unfeasible.
That asymmetry — “easy in one direction, costly in the other” — is the mathematical bedrock of it all. In RSA, the public key contains the product n = p·q of two huge prime numbers; recovering p and q from n would force you to factor a multi-thousand-bit integer, a problem with no known shortcut. ECDSA instead uses the arithmetic of elliptic curves, which achieves the same security with far shorter keys.
Hash: the non-repeatable digest of the message
Signing the entire message would be far too slow and would bloat it. The trick is a digest or hash: a function H that turns text of any length into a fixed-size string (256 bits for SHA-256, for example) with three decisive properties:
- Deterministic: the same message always yields the same digest.
- One-way: you cannot rebuild the message from its digest.
- Collision-resistant: finding two distinct messages with the same digest requires astronomical effort.
If a single pixel changes in a document, its SHA-256 changes completely: that is the lever that makes any alteration detectable.
The heart of the process, step by step
Let us put the pieces together. Signing is not encrypting the message — it is encrypting its hash with the private key:
- Sign: the sender computes
hash(message)and transforms it with their private key. That result is the signatures. They send(message, s). - Verify: the receiver applies the sender’s public key to
sand gets a value. In parallel they computehash(message)with the same protocol’s hash function. - Decide: if the two match, the signature is valid; otherwise the message or the signature has been tampered with.
Notice the key detail: only the private key can produce a value that the public key decrypts correctly. Anyone can verify with the public key, but only the owner of the private key can sign. That is why a valid signature is cryptographic proof of authorship.
RSA versus ECDSA: two ways to sign
In RSA, signing means raising the hash to the power of the private key (s = hd mod n) and verifying raises it to the public key. It is deterministic and easy to implement, but the keys must be long (3072 or 4096 bits) because of progress in factorization.
ECDSA, by contrast, is probabilistic: it produces the signature as a pair of integers (r, s) that depend on a random value k, like a unique wedge per message. It delivers the same security with 256-bit keys and fits into a compact space over HTTPS — which is why the X25519 and P-256 curves dominate the modern web. Reusing the same k for two messages shatters the security completely: that was the flaw that exposed PlayStation 3 keys back in 2010.
What it protects — and what it does not
The signature guarantees integrity, authenticity and non-repudiation of the content, but it encrypts nothing: anyone receiving it can read the message. It also does not protect against replay: an attacker can re-send a validly signed message (say, a payment order) and it works again. Above all, it depends on the public key arriving over a trusted channel: that is what X.509 certificates and certification authorities are for, closing the chain with the TLS channel.
Where you see it working every day
- TLS certificates: the server signs a random challenge to prove it owns the certificate’s private key.
- Secure email and documents (signed PDFs, S/MIME).
- Updates and packages: signed Git commits, systemd packages and appimages verified before execution.
- Software bills of materials and OCI container signatures in supply chains.
Next time you see a padlock in your browser bar, remember: before a single byte of the site is sent, the server had to prove, with a signature, that it owned that private key. That cryptographic handshake is the glue that holds the trust of the whole web together.
