← Back to Table of Contents

Digital Signatures

We’ve solved confidentiality (encryption) and integrity (hashing). Now we need authentication: how do you prove that a message came from who it claims to come from?

The Problem

Imagine you receive an email that says “Transfer $50,000 to account XYZ, signed by the CEO.” How do you know the CEO actually sent it? Anyone could type those words. You need a way for the CEO to “sign” the message in a way that:

  1. Only the CEO can produce the signature
  2. Anyone can verify the signature is genuine
  3. The signature is tied to the specific message (can’t be copied to a different message)

Physical signatures on paper sort of work for this, but they can be forged, and they’re not tied to the content of the document. You could cut a signature off one document and paste it onto another.

Digital signatures solve all three problems using asymmetric cryptography.

How Digital Signatures Work

Remember asymmetric encryption? Public key encrypts, private key decrypts. Digital signatures flip this around:

Here’s the process:

  1. The sender hashes the message (producing a fixed-size fingerprint)
  2. The sender encrypts the hash with their private key. This encrypted hash is the signature.
  3. The sender sends the message plus the signature
  4. The receiver hashes the received message
  5. The receiver decrypts the signature with the sender’s public key, recovering the original hash
  6. The receiver compares the two hashes. If they match, the signature is valid.
sequenceDiagram
    participant S as Sender
    participant R as Receiver

    S->>S: Hash the message
    S->>S: Encrypt hash with private key = signature
    S->>R: Message + Signature

    R->>R: Hash the received message
    R->>R: Decrypt signature with sender's public key
    R->>R: Compare hashes
    Note over R: Match = authentic and unmodified
    Note over R: Mismatch = forged or tampered

Why This Works

Only the sender has the private key, so only they can produce the signature. Anyone can verify it with the public key, but no one can forge it.

The signature is tied to the specific message because it’s a signed hash of that message. If you change even one bit of the message, the hash changes, and the signature no longer matches. You can’t take a signature from one message and attach it to a different message.

This gives us three things at once:

Where Signatures Show Up in TLS

Digital signatures are used in two critical places in TLS:

1. Certificates. A certificate is a document that binds a public key to an identity (like a domain name). The certificate is signed by a Certificate Authority (CA) using the CA’s private key. Your browser verifies the signature using the CA’s public key. This is how your browser knows the server’s public key is legitimate.

2. The handshake. During the TLS handshake, the server signs certain handshake messages with its private key. This proves the server actually possesses the private key that matches the certificate. Without this step, an attacker could steal a certificate (which is public) and pretend to be the server. The signature proves they have the private key too.

Signing vs Encrypting

It’s easy to confuse signing and encrypting because they both use key pairs. Here’s the difference:

Encryption Signing
Purpose Confidentiality Authentication + Integrity
Who uses the public key? Sender (to encrypt) Receiver (to verify)
Who uses the private key? Receiver (to decrypt) Sender (to sign)
What it proves Only the private key holder can read it Only the private key holder could have sent it

Encryption protects the content. Signing proves the origin.

In TLS, both are used. Encryption (via key exchange) protects the data. Signing (via certificates and handshake messages) proves identity.

Next: RSA, ECDSA, and EdDSA

← Previous ChapterNext Chapter →