Digital signatures and certificates

Encryption keeps a message secret — a snooper on the wire sees only ciphertext. But secrecy answers only one of the questions that matter online. Suppose an email arrives that says "This is your bank. Transfer £500 to account 12345678." Two new worries appear that encryption alone does nothing about:

Did it really come from who it claims? Anyone can put "your bank" in the From line. This is the question of authenticity.
Has it been changed in transit? A message could be intercepted and the account number quietly swapped. This is the question of integrity.

A digital signature answers both at once. It is a small piece of data attached to a message that lets anyone check that it genuinely came from a particular sender and that not one bit has been altered since they signed it. It cleverly combines the two ideas you already know — asymmetric key pairs and hashing — to do something neither could do alone.

The two ingredients you already have

A digital signature is built from two tools from earlier pages, so it's worth a quick recap of exactly what each one gives us.

From asymmetric encryption: every person has a key pair — a private key they keep secret and a public key they hand out freely. The pair is mathematically linked: anything scrambled with one key can only be unscrambled with the other. For secrecy we usually encrypt with someone's public key so only they (with the private key) can read it. A signature, as we'll see, does the reverse.
From hashing: a hash function boils a message of any length down to a short, fixed-size digest (a "fingerprint"). It is one-way, and — crucially — changing even a single character produces a wildly different digest. So if two digests match, the two messages are (to all practical certainty) identical.

Hold those two facts in mind: a signature proves identity using the key pair, and proves the message is unchanged using the hash.

Signing: hash, then encrypt the hash with your private key

Here is the whole recipe for the sender (call her Alice):

Alice hashes her message to get a digest.
She encrypts that digest with her PRIVATE key. The encrypted digest is the digital signature.
She sends the message and the signature together.

Because Alice is the only person on Earth who holds her private key, she is the only person who could have produced that particular signature for that message. That is what ties the signature to her.

\text{signature} \;=\; \text{Encrypt}_{\;\text{Alice's private key}}\big(\;\text{hash}(\text{message})\;\big)

Verifying: decrypt with the public key, then re-hash and compare

Now the receiver (Bob) checks it. He has Alice's public key.

Bob decrypts the signature with Alice's PUBLIC key. Out pops the digest Alice hashed — call it digest A. (Only Alice's public key can undo what her private key did, so a successful decrypt already tells Bob it was Alice.)
Bob hashes the message he actually received himself, giving digest B.
He compares them. If digest A = digest B, the message is authentic (it came from Alice) and has integrity (nobody changed it). If they differ, he rejects it.

Follow the whole flow, step by step:

Notice how a tampered message breaks the check: if an attacker alters even one character, Bob's digest B no longer matches digest A, and the signature fails. And because they can't produce a valid new signature (that would need Alice's private key), they can't fix it either.

Three guarantees in one

A valid digital signature delivers three properties at once:

Authenticity — it really came from the holder of that private key.
Integrity — the message is byte-for-byte what was signed; any change is detected.
Non-repudiation — Alice cannot later deny sending it, because only her private key could have created the signature. In a dispute, the signature is evidence.

Note what it does not do: a signature does not keep the message secret. The message still travels in the clear alongside its signature. If Alice also wants secrecy, she encrypts the message for Bob as well as signing it — the two are independent jobs, often used together.

To sign: the sender encrypts the hash of the message with their private key.
To verify: the receiver decrypts the signature with the sender's public key and checks it equals a fresh hash of the received message.
A match proves authenticity, integrity and non-repudiation — but not confidentiality.

See the logic run

The code below is a toy to show the logic (real signatures use industrial hashing and asymmetric maths, not this). sign hashes the message and "encrypts" the digest with a private secret; verify "decrypts" with the matching public secret and checks it against a fresh hash. Press Run and watch the genuine message pass and the tampered one fail:

// A toy hash — a real one (e.g. SHA-256) is far stronger, but this shows the idea. function hash(text: string): number { let h: number = 0; for (const ch of text) h = (h * 31 + ch.charCodeAt(0)) % 1000000; return h; } // Pretend key pair. "Signing" transforms a digest with the PRIVATE secret; // "verifying" reverses it with the matching PUBLIC secret. Real crypto does this // with one-way maths, but the round-trip property is the same. const PRIVATE: number = 424242; function encryptWithPrivate(d: number): number { return d + PRIVATE; } function decryptWithPublic(sig: number): number { return sig - PRIVATE; } function sign(message: string): number { return encryptWithPrivate(hash(message)); // hash, then sign the hash } function verify(message: string, signature: number): boolean { return hash(message) === decryptWithPublic(signature); // re-hash and compare } const message: string = "Transfer 50 pounds to Sam"; const signature: number = sign(message); console.log("Signature:", signature); console.log("Genuine message verifies? ", verify(message, signature)); // An attacker swaps the message but reuses Alice's old signature... const tampered: string = "Transfer 500 pounds to Eve"; console.log("Tampered message verifies? ", verify(tampered, signature));

The genuine message verifies; the tampered one does not, because its hash no longer matches the digest hidden inside the signature. That single false is integrity and authenticity working.

This trips up almost everyone, so pin it down. A key pair is used in two opposite ways depending on the goal:

For secrecy (encryption): you encrypt with the recipient's PUBLIC key, and only they can decrypt with their private key. The public key locks; the private key unlocks.
For a signature: you sign with your own PRIVATE key, and anyone can verify with your PUBLIC key. The private key "locks"; the public key "unlocks".

It flips because the two goals are mirror images. Secrecy asks "only one person should be able to read this" — so lock with the key everyone has and unlock with the key one person has. A signature asks "everyone should be able to check that one person made this" — so lock with the key one person has and unlock with the key everyone has. Same key pair, opposite roles. If you ever "sign with a public key" you've got it backwards.

But how do you trust the public key itself?

There's a hole in the story. Verifying Alice's signature needs Alice's genuine public key. But what if an attacker, Mallory, hands Bob her own public key while claiming it's Alice's? Then Mallory can sign messages with her private key, Bob verifies them against the fake "Alice" public key, and they look perfectly authentic. The maths is sound — the problem is Bob was given the wrong key. Nothing so far tells him which public key really belongs to Alice (or to www.yourbank.co.uk).

This is the key-distribution problem, and the fix is a digital certificate.

Digital certificates and Certificate Authorities

A digital certificate is a small document that binds a public key to an identity (a person, or a website's domain name). Crucially, the certificate is itself digitally signed — not by the owner, but by a trusted third party called a Certificate Authority (CA) (real examples: DigiCert, Let's Encrypt, GlobalSign).

A certificate typically contains:

the identity it vouches for (e.g. www.bbc.co.uk);
that identity's public key;
the CA's name and an expiry date;
the CA's digital signature over all of the above.

Now the trust becomes a chain. Your browser ships with a built-in list of a few trusted CAs and their public keys. When a site presents its certificate, the browser uses the CA's public key to verify the CA's signature on it (exactly the sign/verify process from above!). If it checks out, the browser trusts that the public key inside really does belong to that domain — because a CA it already trusts has vouched for the mapping.

This is the machinery behind the HTTPS padlock. When you visit an https:// site, the server sends its certificate; your browser verifies the CA's signature and checks the domain and expiry. Only if everything holds does it show the padlock and set up the encrypted connection. So the padlock isn't just "encrypted" — it also means "a trusted CA vouches that this is really who it claims to be."

A certificate doesn't create trust out of nothing — it delegates it to the CA. That has two consequences worth remembering:

If a CA is careless or is compromised and issues a certificate for a domain to the wrong person, browsers will trust that fake site — the whole system rests on CAs doing their job. (This has happened, and browsers respond by revoking trust in that CA.)
A self-signed certificate (one where the owner is also the "authority") proves nothing to a stranger — anyone can sign their own claim. That's why browsers show a big warning for self-signed certificates: there's no independent party vouching for the identity.

She can copy it — but a signature is bound to one exact message. Reuse it on any different message and the receiver's fresh hash won't match the digest inside the signature, so verification fails. To make a valid signature for a new message she'd need to encrypt that message's hash with Alice's private key — which she doesn't have. This is exactly why the hash step matters: it welds the signature to the precise bytes of the message.

Not at all — and the difference is the whole point. A scanned or drawn "signature" is just an image; anyone can copy-paste it onto any document, and it says nothing about whether the text was changed. A digital signature is computed from the message's contents with a private key, so it detects tampering and can't be transplanted onto another document. It's cryptography, not a picture.