How a digital signature proves who signed

SpecSpec: RFC 5652RFC 5652SpecSpec: RFC 5280, §6RFC 5280 §6SpecSpec: RFC 3161, §1RFC 3161 §1

At a glance

A digital signature does three things, and it is worth keeping them apart from the start: it proves the bytes were not changed, it proves who signed them, and — with a little help — it proves when. This page builds that idea from nothing, so the cryptography stops being a black box.

Why this matters

“Signed” is a word people stake decisions on. A contract, an invoice, a release note for software someone will run. If you only know that a tool printed a green checkmark, you do not actually know what was proven. You might have proof the bytes are intact but no idea whose key signed them. You might have a real signer but a certificate that expired years ago. Understanding the pieces is what lets you say, precisely, what a valid signature means — and, just as usefully, what it does not.

The short version

Picture a tamper-evident envelope with a personal seal pressed into the flap.

• The seal is unique to one person and effectively impossible to forge. Anyone can recognise it; only its owner can make it. That is the key pair: a private key only you hold, and a public key everyone can see.
• You do not press the seal over the whole document. You press it over a tiny, unforgeable summary of it — a hash. Change one byte of the document and the summary changes completely, so the seal no longer fits.
• Signing is producing a signature over the document with your private key — over the hash for RSA and ECDSA, or over the content itself for EdDSA, which does its own hashing inside. Verifying is running the algorithm’s check with your public key, the signature, and the same content (as a hash, or directly) — it returns valid or invalid. Math, not trust, links the two.
• A certificate is the part that says whose seal this is. Without it, you have proven a key signed the bytes, but not that the key belongs to anyone in particular.
• A timestamp is the part that says when. A signer’s own clock is just a claim; trusted time comes from an outside authority.

How NextPDF approaches it

Start with the hash, because everything else stands on it. A cryptographic hash function reads any amount of data and produces a short, fixed-length fingerprint — for a PDF signature, typically a 256-bit value. Two properties make it useful: the same input always yields the same fingerprint, and it is infeasible to find a different input with the same one. So a hash is a faithful stand-in for the document. If two hashes match, the bytes match.

Now the key pair. A private key and a public key are mathematically linked, but you cannot derive one from the other in any practical amount of time. Only the private key can produce a valid signature, and only the matching public key can check it. Signing uses that asymmetry: the signer applies a private-key operation to the input the chosen algorithm defines — the content’s hash for RSA and ECDSA, or the content directly for EdDSA, which hashes internally. The result is the signature value. Because only the holder of the private key could have produced it, and because it is bound to this content, it proves two things at once — the holder signed, and the bytes have not moved since.

Verification mirrors that logic. The verifier reconstructs the same input — hashing the document for RSA and ECDSA, or taking the content directly for EdDSA — then runs the signature algorithm’s verify operation on the public key, the signature value, and that input. The operation returns valid or invalid — and this is the same shape whether the algorithm is RSA, ECDSA, or EdDSA, even though only RSA can be pictured as literally “recovering” the hash. Valid means intact and authentic. Invalid means something changed, or the wrong key was used, and the honest answer is invalid.

1. Prepare the inputRSA and ECDSA hash the document to a short, fixed-length fingerprint; EdDSA signs the content directly and hashes it internally. Either way, any change to the bytes changes what is signed.
2. Sign with the private keyThe signer applies a private-key operation to that input — the hash for RSA and ECDSA, the content for EdDSA. The output is the signature value; only the private-key holder could have produced it.
3. Reconstruct the inputThe verifier independently rebuilds the same input from the content — a recomputed hash for RSA and ECDSA, the content itself for EdDSA. This is what the verify operation checks against.
4. Verify with the public keyThe verifier runs the algorithm's verify operation on the public key, the signature value, and that input. The same shape works for RSA, ECDSA, and EdDSA.
5. Accept or rejectThe verify operation returns valid or invalid. Valid means the bytes are intact and the private-key holder signed them. Otherwise the result is invalid — no guessing.

How a digital signature is produced and then checked, from first principles. The signer produces a signature over the content with their private key — over a hash for RSA and ECDSA, or over the content directly for EdDSA; the verifier reconstructs the same input, then runs the algorithm's verify operation on the public key, the signature, and that input. A valid result proves the bytes are intact and that the private-key holder signed them.

In a real PDF, NextPDF does not press the seal over the visible page — it presses it over a declared range of bytes, and packages the signature as a detached CMS object (SpecSpec: RFC 5652RFC 5652) placed inside the file (SpecSpec: ISO 32000-2, §12.8ISO 32000-2 §12.8). One refinement matters: the signer does not sign the raw content hash directly. It signs a small set of signed attributes that include the content’s hash, so the time, the content type, and the signer’s certificate identifier are all sealed together. Where those bytes live, and why the range is shaped the way it is, is the subject of How signatures sit in a PDF.

So far, the math proves a key signed these bytes. It says nothing about whose key. That gap is exactly what a certificate fills. A certificate is itself a signed statement — from a certificate authority — that this public key belongs to this named subject. Trusting it means following the chain from the signer’s certificate up to an authority you have decided to trust, checking every link’s validity along the way (SpecSpec: RFC 5280, §6RFC 5280 §6). Without that chain, “signed” is anonymous. With it, “signed” has a name.

The last piece is when. A signature can embed the signer’s own claimed time, but a clock you do not control is a claim, not a proof. A timestamp from a Time-Stamp Authority binds a hash of the signature to an instant, attested by a party with no stake in the document (SpecSpec: RFC 3161, §1RFC 3161 §1). That is what lets a signature remain meaningful after the signer’s certificate expires: you can show the signature existed while the certificate was still valid. The deeper treatment is in Timestamps and trusted time.

Practical example

The shapes below are the conceptual operations, written plainly. The point is not an API call — it is seeing that sign and verify are mirror images, and that a tampered byte breaks the match by construction.

<?php

declare(strict_types=1);

// SIGN — the holder of the private key seals the content.
// RSA and ECDSA sign a hash; EdDSA signs the content directly (hashing inside).
$signingInput = sign_input($content);            // a digest for RSA/ECDSA, the content for EdDSA
$signatureValue = private_key_transform(         // only the key holder can do this
    privateKey: $signerPrivateKey,
    input: $signingInput,
);

// VERIFY — anyone with the public key runs the algorithm's check.
$recomputedInput = sign_input($content);          // verifier rebuilds the same input
$intactAndAuthentic = signature_verify(           // RSA, ECDSA, EdDSA — same shape
    publicKey: $signerPublicKey,                  // taken from the certificate
    signatureValue: $signatureValue,
    input: $recomputedInput,                       // the freshly reconstructed input
);
// true  -> bytes unchanged AND signed by the private-key holder
// false -> a byte changed, or the wrong key — the honest answer is "invalid"

// The certificate answers a SEPARATE question: whose public key is this?
// The timestamp answers ANOTHER: when did this signature exist?
// "intact + authentic" alone proves neither identity nor time.

Forging a change that still verifies is computationally infeasible. The hash carries the content faithfully, so altering the content alters the hash, and the verify operation rejects it — short of finding a hash collision, which the chosen function is designed to make impractical.

Common misconception

The frequent mistake is reading “valid signature” as “trustworthy document.” They are not the same sentence. The cryptography proves the bytes are intact and the private-key holder signed them — nothing more. A document signed with a key you have never heard of, attested by no authority you recognise, can be flawlessly “valid” and worth nothing. Identity comes from the certificate and its chain; time comes from a trusted timestamp. A green checkmark that quietly folds all of these into one boolean has decided, on your behalf, which questions mattered. Knowing the pieces is what lets you ask the rest.

Human-factors note:Human-factors note

The reason to separate these ideas is not pedantry — it is so the word “signed” stays honest. Integrity, identity, and time are three distinct proofs, established by three distinct mechanisms (a hash plus a key pair, a certificate chain, and a timestamp authority). A tool that reports them as one flag is easier to read and far easier to misread. NextPDF keeps them separate, in its output and in its tests, so a result that says “valid” can be unpacked into exactly what was proven.

Limits and boundaries

This page explains the idea of a digital signature, not the full validation procedure. The math here proves integrity and authenticity. It does not, on its own, tell you whether the signing certificate was issued to who you think, whether it was valid at signing time, or whether it was later revoked — those are certificate-path and revocation questions, and a correct validation runs all of them. The complete check set is in Validating a signature properly.

NextPDF builds the signature structure and performs the cryptographic checks. It does not choose your trust anchors, vouch for any certificate authority, or decide the legal effect of a signature — those depend on your deployment, the certificate, and the jurisdiction. The engine proves the mechanism; the trust decisions on top of it are yours.

What the engine ships, by tier, builds outward from this foundation:

Digital signature: integrity, identity, and trusted time — edition availability

Edition	Availability
Core	○ PAdES B-B: the hash-and-sign mechanism described here, packaged as a detached CMS SignedData object, plus certificate-path validation against a trust anchor you supply.
Pro	○ Adds PAdES B-T — a verified RFC 3161 trusted timestamp on the signature value, so the “when” is attested rather than self-claimed.
Enterprise	○ Adds the long-term profiles (B-LT, B-LTA): embedded validation material and document timestamps that keep the identity and time proofs answerable for years.

Related docs

• How signatures sit in a PDF — where the signature value and its byte range actually live in the file.
• Validating a signature properly — the full set of checks a verifier must run, beyond the math on this page.
• Timestamps and trusted time — what an RFC 3161 timestamp proves, and why a signer’s own clock is not it.
• PAdES baseline profiles — which profile layers identity, time, and long-term material onto this foundation.

Glossary

• Hash (digest) — a short, fixed-length fingerprint of data from a cryptographic hash function; any change to the data changes it completely.
• Key pair — a linked private key (held only by the signer) and public key (shared freely); only the private key can sign, and only the matching public key can verify.
• Signing — applying the private-key operation to the input the algorithm defines: a hash of the content for RSA and ECDSA, or the content directly for EdDSA (which hashes internally). In a PDF, that content is the signed attributes, which include the document’s hash. The result is the signature value.
• Verifying — reconstructing the same input (a recomputed hash, or the content directly for EdDSA), then running the algorithm’s verify operation on the public key, the signature value, and that input to get a valid-or-invalid answer.
• Signature value — the bytes the private-key operation produces; what a verifier checks against the freshly reconstructed algorithm input (a digest for RSA and ECDSA, the content itself for EdDSA).
• Certificate — a signed statement binding a public key to a named identity; trusted by chaining to an authority you accept (RFC 5280 §6).
• Trust anchor — a certificate authority you have decided to trust; the root of an acceptable certificate chain.
• Timestamp (RFC 3161) — a signed token from a Time-Stamp Authority binding a hash to a time value, providing trusted proof of when.
• CMS SignedData — the Cryptographic Message Syntax (RFC 5652) structure that carries the signature value and the signer’s certificate.
• PAdES — PDF Advanced Electronic Signatures: the ETSI profile family for PDF signing. Covered in depth on the signing pages.