365 Architect

02 — Digital Signatures Explained

The Analogy: Wax Seal

In medieval times, a noble sealed a document with wax imprinted by their unique signet ring:

  • Anyone could see the seal and know who sent it
  • Only the ring owner could create that exact imprint
  • Tampering broke the seal

Digital signatures are the mathematical equivalent:

  • Public key = the seal design (visible to all)
  • Private key = the ring itself (only the owner possesses it)
  • Signature = the wax imprint (unique to that document and that ring)

How Digital Signatures Work

Step 1: Hash the Message

A hash function (SHA-256) compresses any document into a fixed-size "fingerprint":

Document (any size)
       |
       v
   SHA-256
       |
       v
256-bit hash (32 bytes)

Properties:

  • Deterministic: Same document → same hash
  • One-way: Can't recover document from hash
  • Collision-resistant: Can't find two documents with same hash

Step 2: Sign the Hash

The signer uses their private key to transform the hash into a signature:

Hash (32 bytes) + Private Key
              |
              v
       Signature Algorithm
              |
              v
       Signature (variable size)

This signature is unique to:

  1. The specific hash value (binding to the message)
  2. The specific private key (binding to the identity)

Step 3: Verify the Signature

Anyone with the public key checks:

Signature + Public Key + Original Message
              |
              v
       Verify Algorithm
              |
              v
       Valid / Invalid

The verification algorithm confirms:

  • The signature was created by the matching private key
  • The signature matches this exact message (any change invalidates it)

Required Properties

Property What it means Real-world analogy
Correctness Valid signatures always verify A real seal always matches its ring
Unforgeability Without the private key, creating a valid signature is computationally impossible Without the ring, you can't make the imprint
Non-repudiation The signer can't claim they didn't sign The noble can't deny their seal
Integrity Any message change invalidates the signature Breaking the seal reveals tampering
Transferability Anyone can verify with the public key Anyone can inspect a wax seal

Types of Signature Schemes

Type Examples Key characteristic
RSA RSA-PSS, RSA-PKCS#1 v1.5 Based on integer factorisation
Discrete log DSA, ECDSA, EdDSA Based on discrete logarithm
Lattice-based ML-DSA, FN-DSA Based on lattice short vector problems
Hash-based SLH-DSA (SPHINCS+) Based only on hash function security

Signature Format: X.509

In practice, signatures live inside X.509 certificates:

Certificate:
  Version: 3
  Serial Number: 123456789
  Issuer: CN=Example CA
  Subject: CN=docs.365architect.com
  Subject Public Key Info:
    Algorithm: ML-DSA-65
    Public Key: [1,952 bytes]
  Validity:
    Not Before: 2026-01-01
    Not After: 2027-01-01
  Signature Algorithm: ML-DSA-65
  Signature: [3,293 bytes]

The Subject Public Key Info contains the signer's public key (for verifying their signatures). The Signature at the bottom is the CA's signature on this certificate (proving the CA vouches for this public key).

Chain of Trust

Root CA (self-signed)
    |
    signs
    |
Intermediate CA
    |
    signs
    |
End-entity certificate (your website)

Your browser trusts the Root CA's public key (pre-installed). It verifies the chain:

  1. Check Intermediate CA's signature using Root CA's public key
  2. Check your certificate's signature using Intermediate CA's public key
  3. Verify your server's signature using your certificate's public key

Resources

  • RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  • RFC 8446: TLS 1.3 (certificate structure)
  • NIST FIPS 186-5: Digital Signature Standard (pre-PQC)
★★★★★
Share on LinkedIn