Digital Signatures

A digital signature is a cryptographic proof that a specific entity created or approved a piece of data, and that the data hasn’t been modified since signing. The signer hashes the data and encrypts the hash with their private key. Anyone with the signer’s public key can decrypt the signature, compute their own hash of the data, and compare — if they match, the signature is valid. Unlike a handwritten signature (which can be forged), a digital signature is mathematically bound to both the signer’s key and the exact content signed.

Why it matters

• Certificate trust — every X.509 certificate is a digital signature. The CA signs the certificate’s contents (subject, public key, validity) with its private key. Clients verify this signature to trust the certificate.
• Non-repudiation — the signer cannot deny having signed. Only the holder of the private key could have produced the signature. This has legal standing in many jurisdictions (eIDAS in EU, ESIGN Act in US).
• Code integrity — signed software (executables, packages, firmware) proves the code came from the claimed publisher and hasn’t been tampered with. Package managers (apt, npm, Docker) verify signatures before installation.
• Document authenticity — signed PDFs, contracts, and transactions prove who approved them and that content hasn’t changed. Critical for legal, financial, and healthcare workflows.
• TLS handshake authentication — in TLS 1.3, the server signs the handshake transcript (CertificateVerify message) proving it holds the private key matching its certificate. This prevents man-in-the-middle attacks.

How it works

Signing:

1. Compute hash of the message: h = SHA-256(message)
2. Encrypt the hash with signer’s private key: signature = Sign(h, private_key)
3. Attach signature to the message (or transmit separately)

Verification:

1. Compute hash of the received message: h' = SHA-256(message)
2. Decrypt the signature with signer’s public key: h = Verify(signature, public_key)
3. Compare: if h == h', signature is valid (authentic + unmodified)

Algorithms:

• RSA-PSS — RSA with Probabilistic Signature Scheme. Produces different signatures for the same input (randomized padding). Preferred over PKCS#1 v1.5.
• ECDSA — Elliptic Curve Digital Signature Algorithm. Smaller signatures (64 bytes for P-256 vs 256 bytes for RSA-2048). Requires careful nonce handling.
• Ed25519 — Edwards-curve signature. Deterministic (no random nonce needed), fast, constant-time. Preferred for new systems.

In real systems

TLS CertificateVerify (TLS 1.3):

# Server proves it owns the certificate's private key by signing the handshake:
CertificateVerify {
  algorithm: ecdsa_secp256r1_sha256
  signature: <ECDSA signature over handshake transcript hash>
}
# Client verifies using the public key from the server's certificate
# If verification fails → handshake aborted, connection refused

Code signing (Windows Authenticode):

# Sign an executable
signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 \
  /f code-signing-cert.pfx /p password MyApp.exe

# Verify signature
signtool verify /pa /v MyApp.exe

Git commit signing:

# Sign commits with GPG key
git config --global commit.gpgsign true
git commit -m "Fix vulnerability" -S

# Verify a signed commit
git verify-commit HEAD
# gpg: Signature made Mon Apr 28 10:15:00 2026
# gpg: Good signature from "Developer <dev@example.com>"

OpenSSL signature operations:

# Sign a file
openssl dgst -sha256 -sign private.key -out signature.bin document.pdf

# Verify the signature
openssl dgst -sha256 -verify public.key -signature signature.bin document.pdf
# Output: Verified OK

Where it breaks

Signature valid but certificate expired/revoked — a document was signed with a valid certificate in 2024. In 2026, the certificate has expired. Is the signature still valid? It depends on whether a timestamp was included. Without a trusted timestamp, the verifier can’t prove the signature was created while the certificate was valid. Code signing and document signing must include RFC 3161 timestamps — otherwise signatures become unverifiable after certificate expiry.

Signing the wrong thing — a developer signs a build artifact, but the CI/CD pipeline modifies the artifact after signing (adds metadata, repackages, compresses). The signature no longer matches the delivered artifact. Signing must be the last step before distribution — nothing can modify the signed content afterward. This is a common mistake in complex build pipelines.

ECDSA nonce reuse — ECDSA requires a unique random nonce for each signature. If the same nonce is used twice with the same key (or if the nonce is predictable), the private key can be mathematically recovered from two signatures. This is not theoretical — it has been exploited against Sony (PS3), Bitcoin wallets, and various IoT devices. Use deterministic ECDSA (RFC 6979) or Ed25519 to eliminate this class of vulnerability entirely.

Operational insight

Digital signatures create a long-term verification problem. A signature made today with SHA-256 and ECDSA P-256 is secure. But in 15 years, will the algorithm still be trusted? Will the signing certificate’s CA still exist? Will the revocation infrastructure still be queryable? For long-lived signatures (legal documents, property records, archival), you need a re-signing strategy: periodically re-sign with current algorithms and fresh timestamps before the old algorithms are deprecated. The EU’s eIDAS regulation addresses this with “preservation” services that maintain signature validity across algorithm transitions. Without this planning, signatures on 20-year-old documents become unverifiable.

Related topics

• What is Asymmetric Encryption
• What is Hashing
• RSA Algorithm Explained
• Elliptic Curve Cryptography
• What is Code Signing