Digital Signatures Explained: Hashing, Key Pairs & Document Integrity

For most of history, a signature proved intent through physics: the uniqueness of your handwriting, witnessed on paper. A digital signature replaces ink with mathematics — and in doing so becomes something a scribble could never be: a tamper-evident seal that fails loudly if a single byte of the document changes. This guide explains the machinery step by step, without requiring a cryptography background.

Step one: condense the document with a hash

Signing a 40-megabyte contract byte-by-byte would be absurd. Instead, the document is first passed through a cryptographic hash function — today almost always SHA-256 — which compresses any input, of any size, into a fixed 256-bit digest:

Deterministic. The same input always yields the same digest; verification depends on this.
Avalanche effect. Changing one comma in the contract changes roughly half the bits of the digest.
Collision resistance. Finding two different documents with the same SHA-256 digest would require on the order of 2¹²⁸ operations — famously demonstrated as infeasible (MD5 and SHA-1, which fell to collisions, are the cautionary tales).

The digest is the document's fingerprint: short, unique-in-practice, and impossible to reverse into the original text.

Step two: sign the fingerprint with a private key

Hashing alone proves integrity only if someone you trust computed the hash. The revolution is asymmetric cryptography: a mathematically linked key pair where

the private key produces the signature (you never share it, ideally never even copy it), and
the public key verifies it (you can publish it on a billboard).

The signature algorithm — RSA or, in modern systems, ECDSA on curves like P-256 — binds the digest to the private key with a computation that is easy to perform and computationally infeasible to forge or reverse. Crucially, signing is not encryption: a signature provides proof, not secrecy. Confidentiality is a separate operation with separate keys.

What a signature proves — and what it doesn't

Guarantee	Meaning
Integrity	Not one byte has changed since signing — including invisible metadata.
Authenticity	The holder of the private key signed it; if keys are managed well, that's the named signer.
Non-repudiation	The signer cannot credibly deny signing (legal weight varies by jurisdiction, e.g. eIDAS in the EU, ESIGN in the US).
Not confidentiality	Anyone can read a signed document. Signing ≠ encrypting.
Not endorsement	A valid signature on malicious content is still valid. Signatures prove provenance, not virtue.

Trust chains: who vouches for the public key?

Verification has a stubborn dependency: how do you know a public key belongs to the person it claims? The Public Key Infrastructure (PKI) answers with chains of X.509 certificates: a Certificate Authority (CA) verifies your identity and signs a certificate binding your name/organisation to your key. Verifiers walk the chain — your certificate → issuing CA → trusted root — and check revocation status along the way.

Self-signed certificates prove consistency only (“this key signs itself”), suitable for personal archives and internal tooling.
CA-issued certificates add an accountable third party, which is what regulated e-signing workflows and PDF “trusted seal” signatures require.
Trusted timestamps (RFC 3161) complete the picture: a timestamp authority signs “this signature existed at time T”, so signatures remain verifiable even if the private key is later compromised or revoked.

Inside a signed PDF (briefly)

PDF signatures are clever bookkeeping. The signer computes a ByteRange digest covering the entire file except a reserved hole, then inserts the signature container (CMS/PKCS#7 — carrying the certificate chain and timestamp) into that hole. Any later edit shifts bytes outside the reserved space, breaking the digest: the viewer shows a yellow or red warning instead of a green check. Signatures can stack incrementally — each new one covers everything before it, producing a legible audit trail of who signed what, in which order.

The private key is the signature. Guard it like the document's soul: generated locally, stored in an OS keystore or hardware token, and never transmitted to a web service.

Why signing belongs on your side of the network

Consider the custody chain of an e-signing site that processes documents server-side: your contract — salaries, terms, personal data — is uploaded, hashed on their hardware, and the operation's logs now reference your confidential file. The cryptographic strength is unchanged, but the privacy model is terrible. Everything except (optionally) timestamping is local arithmetic: hashing and ECDSA run in microseconds inside the WebCrypto API or WebAssembly. sign.clicktools.app is engineered so keys are generated and used inside your browser, documents are hashed in memory, and only you ever possess both the file and the key.

The takeaway

A digital signature is a three-layer sandwich: a hash that detects any change, a key pair that binds the hash to an identity, and a trust chain that makes the identity meaningful. Understand those layers and you can read signature warnings like an auditor — and insist on tooling that keeps private keys and documents on your side of the wire, where they belong.