Digital Signatures and PDF Security: How They Actually Work

What a Digital Signature Is Not

A digital signature is not a scanned image of your handwritten signature dropped onto a document. That's an image. It proves nothing about who created the file or whether the content has changed since signing. Anyone with a graphics editor can copy that image to any document.

A cryptographic digital signature is something fundamentally different. It's a mathematical proof, derived from the document's actual content and tied to a private key that only the signer possesses, that simultaneously identifies the signer and guarantees the document hasn't been altered. Change even a single byte after signing and the signature becomes invalid.

Understanding how this works is worth five minutes — it explains why digital signatures are trusted for contracts, and why a scanned signature isn't.

The Signing Process

Digital signatures use asymmetric cryptography (also called public-key cryptography). The signer has two mathematically linked keys: a private key that they keep secret and a public key that they share with anyone who needs to verify their signatures.

Here's what happens when you digitally sign a PDF:

1. Hash the document. A cryptographic hash function (SHA-256 is standard) processes the entire document content and produces a fixed-length digest — typically 256 bits. This digest is a fingerprint of the document. Change anything in the document and the hash changes completely.

2. Sign the hash with your private key. The private key is used to cryptographically sign the hash digest — in RSA-based schemes this involves a modular exponentiation with the private key; in ECDSA it involves elliptic-curve arithmetic. The result is the digital signature, stored in the PDF alongside the document content.

3. Embed the signer's certificate. The PDF also stores the signer's public key certificate, which contains their public key and identity information, signed by a Certificate Authority (CA).

Document content → SHA-256 hash → Signed with private key → Signature bytes

That's it. The signature is essentially: "here is proof that someone with this private key saw this exact version of this document."

The Verification Process

Anyone with the signer's public key can verify the signature. This is the important asymmetry: signing requires the private key, but verification is open to everyone.

1. Verify the signature. Use the signer's public key (from the embedded certificate) to verify the signature bytes and recover the original hash. In RSA schemes this is mathematically the inverse of signing; in ECDSA the algorithm verifies the signature directly without recovering a plaintext hash.

2. Hash the document again. Compute a fresh SHA-256 hash of the document content as it exists now.

3. Compare the two hashes. If they match, the document hasn't been modified since signing. If they don't match, something changed — either the document was tampered with, or the signature is invalid.

PDF viewers like Adobe Acrobat and Foxit do this automatically and show a green checkmark or a warning. When a document fails verification, it's either tampered, or the certificate chain has a problem.

Certificate Chains and Trust Anchors

How do you know the signer's public key actually belongs to who they claim to be? That's where Certificate Authorities come in.

A digital certificate is a public key bundled with identity information (name, organization, email) and a digital signature from a CA that vouches for it. The CA's signature on the certificate can itself be verified using the CA's public key — and that CA's certificate is signed by a root CA. This chain continues up to a root certificate that your operating system or PDF viewer pre-installs as trusted.

When Acrobat says "signed by Alice Smith, identity verified," it means: Alice's certificate was signed by a CA your system trusts, and the document hasn't changed since Alice's private key signed it.

This is why self-signed certificates (where you sign your own certificate) show warnings — there's no trusted third party vouching for the identity claim. Self-signed signatures still prove document integrity; they just don't prove identity.

PDF Encryption and Permissions

Separate from signatures, PDF supports two types of password protection, using AES-256 encryption (older files may use 128-bit RC4, which is now considered weak):

User password (document open password): Required to open the file at all. If you don't have this password, you see nothing. The content is encrypted and unreadable without it.

Owner password (permissions password): The file opens without it, but it restricts what you can do: print, copy text, annotate, fill forms, modify content. These restrictions are enforced by compliant PDF viewers. They can be bypassed by tools that ignore permissions, so they're not a security measure against a determined adversary — they're a policy signal for compliant software.

Encryption: AES-256
User password: required to open
Owner password: restricts print/copy/modify

A password-protected PDF with a strong user password and no owner password is genuinely secure for content protection — the encrypted ciphertext is meaningless without the password. The PDF Merge tool handles already-unlocked PDFs; if you're working with locked PDFs programmatically, you need the password to decrypt before processing.

Long-Term Validation (LTV)

Signatures depend on certificate validity. But certificates expire, and CAs can revoke certificates if a private key is compromised. What happens to a signed document years after the signing certificate expires?

Long-Term Validation (LTV) is the PDF standard's answer. At signing time, the document embeds:

• The complete certificate chain (not just the signer's certificate)
• A certificate revocation check result (via OCSP or a CRL)
• A timestamp from a trusted timestamping authority

The embedded timestamp proves when the signature was created. The embedded revocation status proves the certificate was valid at that time. Future verifiers don't need to query any online service — all the validation evidence is inside the PDF. This is how signed contracts remain cryptographically verifiable decades later.

Without LTV, a signature validated years later might fail because the CA's OCSP responder is gone, the CRL is no longer published, or the certificate chain can't be constructed. LTV archives everything needed for perpetual verification.

For a secure hash of document contents outside of PDF — useful for verifying file integrity after download or transmission — the Hash Generator computes SHA-256 and other algorithm outputs directly in your browser. For background on the asymmetric cryptography that powers digital signatures, Public Key Cryptography Explained covers the math and real-world usage. And for the foundational PDF file structure that signatures attach to, How PDF Works explains the xref table, content streams, and how signature objects are stored in the PDF body.