Free — no signup required

Digital Signatures: Authentication and Non-Repudiation

2 min read

How Digital Signatures Work

A digital signature combines hashing and asymmetric encryption to prove both the identity of the sender and the integrity of the data. It answers two questions simultaneously: "Did this data come from who I think it did?" and "Has this data been modified since it was signed?"

The process works as follows:

Signing (done by the sender with their private key):
1. The sender computes a hash of the document: SHA-256(document) → "abc123..."
2. The sender encrypts that hash using their private key: RSA_encrypt(private_key, "abc123...") → signature
3. The sender distributes the document and the signature together.

Verification (done by the recipient with the sender's public key):
1. The recipient computes their own hash of the received document: SHA-256(document) → "abc123..."
2. The recipient decrypts the signature using the sender's public key: RSA_decrypt(public_key, signature) → "abc123..."
3. If the two hashes match, the signature is valid — the document came from the private key holder and has not been modified.

Why This Works

Only the holder of the private key could have produced a signature that decrypts correctly with the corresponding public key. This provides authentication — proof of identity. And because the signature covers the hash of the document, any modification to the document changes the hash, causing the comparison to fail. This provides integrity. Together, they also provide non-repudiation — the signer cannot later claim they didn't sign it, because only their private key could have produced that signature.

Real-World Applications

Digital signatures are everywhere in the software supply chain:

  • Code Signing: Software publishers sign their executables. Your OS verifies the signature before running the installer, ensuring it came from the legitimate publisher and wasn't modified.
  • Git Commit Signing: Developers sign commits with their GPG key (git commit -S). This proves a commit actually came from the claimed author and wasn't injected by an attacker with repository access.
  • TLS Certificates: Certificate Authorities (CAs) digitally sign your server's public key, creating a certificate. Your browser verifies this signature to confirm it's talking to the legitimate server.
  • Package Managers: apt, yum, and npm verify package signatures before installation to prevent supply chain attacks.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free