What's the Difference Between Hash and Digital Signature?

July 24, 2026 ·Gustav Poola ·

digital-signaturecryptographic-hashsha-256integrityauthenticitynon-repudiationadeseidasglobal-digital-identityauthentication

A hash is a fixed-length fingerprint of data — deterministic, one-way, and collision-resistant. A digital signature is a hash that has been transformed by a private key so that anyone with the matching public key can verify both the hash and its origin. Hashing gives you integrity; signing gives you integrity plus authenticity plus non-repudiation. Every digital signature contains a hash. Every hash is not a signature.

What's the Difference Between Hash and Digital Signature?

A Prague-based data-warehouse platform's security engineer sent a screenshot of an internal architecture-review debate last month: half the team was arguing that the platform should be signing every log entry it wrote; the other half was arguing that hashing was enough. Both positions were technically defensible, and both were arguing past each other because the two operations answer different questions. Hashing proves the data hasn't changed since a specific moment. Signing proves who produced the data. The choice between them depends on which of those two properties the deployment actually needs — and, in most real systems, whether it needs both. This post is the difference, walked through at the level a technical review needs to actually reach a decision.

What is a cryptographic hash, and what does it prove?

A deterministic, one-way, collision-resistant mapping from arbitrary-length input to fixed-length output. Given a document, it produces a fingerprint. Given the fingerprint, it does not let you recover the document.

The canonical family in 2026 production is SHA-2 as defined in FIPS 180-4 — the same family the IETF profiled for internet use in RFC 6234. The workhorse variant is SHA-256, producing a 256-bit (32-byte) digest that is small enough to embed anywhere, large enough to make collision search computationally infeasible with current known techniques. Higher-assurance contexts use SHA-384 or SHA-512. The SHA-3 family in FIPS 202 is standardised and available but sees less adoption in AdES deployments in 2026; SHA-256 remains the default for signature-hash purposes.

Three properties matter for a hash function to be cryptographically useful:

Deterministic. The same input always produces the same output. If a hash function returned different values for the same input across runs, it would be useless as an integrity check.

One-way (pre-image resistance). Given a hash value, it is computationally infeasible to find any input that produces that hash. This is what makes a hash a fingerprint rather than a compressed encoding — you cannot decompress it back to the original.

Collision-resistant (second pre-image resistance). Given an input and its hash, it is computationally infeasible to find a different input that produces the same hash. This is what makes hash-based integrity checks trustworthy — an adversary cannot substitute a different document that hashes to the same value.

The property SHA-256 provides at the algorithm layer is integrity — proof that the document hasn't been altered since the hash was computed. Compute the hash of a document at time T. Store the hash somewhere trustworthy. At time T+N, recompute the hash and compare. If the hashes match, the document is bit-identical to what was hashed at time T. If they don't match, something has changed. That's what a hash proves, and it's the only thing a hash proves.

What a hash does not prove is who produced it. Anyone can hash a document; the operation requires no secret. If Alice hashes a document and Bob hashes the same document, they produce identical values. The hash carries no identity information. That is the property signatures add.

What does a private key add on top of the hash?

Authenticity — the ability to demonstrate that a specific person (or key holder) produced the signature — and, in combination, non-repudiation.

A digital signature at the algorithm layer is a transformation of a hash by a private key, using an asymmetric-cryptography primitive. Under RSA-PSS in RFC 8017, the transformation is modular exponentiation with padding; under ECDSA in RFC 6979, it is scalar multiplication on an elliptic curve; under Ed25519 in RFC 8032, it is a deterministic operation on the twisted Edwards curve. In every case, the inputs are the hash and the private key, and the output is a signature that can be verified against the corresponding public key without needing the private key at all. That is the asymmetric-cryptography property: the ability to publish the public key so anyone can verify signatures, while the private key stays with the signer.

What the signature proves is that whoever produced it held the private key at the moment of signing. If the private key is bound to a specific person through a certificate — which walks through the identity-verification chain we covered in our earlier post on the identity proof behind digital signatures — then the signature proves that person produced it. The certificate identifies the key holder; the signature demonstrates the key holder acted.

This is where three properties stack:

Integrity. The signature contains a hash of the document. If the document changes, the hash changes, and the signature no longer verifies. This is the property the hash contributes.

Authenticity. The signature was produced by whoever held the private key. Combined with a certificate that identifies the key holder, this is the property the private-key transformation adds.

Non-repudiation. The signer cannot later deny having signed, because only their private key could have produced the signature. This is the property the whole chain — signature, certificate, retained proofing evidence — establishes, and it is the legal outcome our earlier post on denying a signature walked through in detail.

A hash alone gives you the first property. A signature gives you all three. That is what "signing" adds on top of "hashing" — and it is what a deployment needs when integrity is not enough.

Where does the difference matter operationally — verification, storage, integrity checks?

At the deployment decision point: what property does the system actually need to demonstrate, and to whom?

Log integrity and tamper detection: hash is sufficient. If a system needs to detect whether a log file has been altered since it was closed, and the parties trusting the log include only the system itself (or a chain of custody within a single organisation), a hash is the correct primitive. Compute the hash when the log is written, store the hash separately from the log (in an append-only ledger, a WORM storage, a hash chain), and verify by recomputation later. No identity claim is being made; no external party needs to prove who wrote the log; the property being demonstrated is bit-identity to the original. This is what most immutable-log systems use, and it is why hashing dominates that category.

Document authorship or authorisation across parties: signature is required. If a system needs to demonstrate to a downstream party — a customer, an auditor, a regulator, a court — that a specific person or organisation produced a specific document, hashing alone will not do. The downstream party has no way to verify that the hash they see was produced by the party asserting the document, because anyone can hash. A signature is what allows the downstream verifier to check both integrity and authorship without needing to trust an intermediary. Contracts, ePrescriptions, financial instructions, cross-border transport documents — every regulated document flow that has to satisfy a third-party verifier operates in the signature space.

Storage layer combinations. The distinction matters at retention time too. A signed document typically stores three things together: the document itself, the signature (which contains the hash), and the certificate identifying the signer. If storage is constrained or the format doesn't support embedded signatures, a common pattern is to store the hash-plus-signature separately from the document — the document lives in a filesystem, the signed hash lives in a signing service's database, and the two are linked by identifier. Under PAdES / XAdES / CAdES formats, the signature envelope embeds the hash together with the certificate chain and validation data; the storage question becomes whether the deployment can accept that envelope format, and whether the receiving systems can consume it. A Vienna-based long-term-storage platform we advised in 2025 discovered mid-integration that their content management system stripped PDF signature envelopes on ingestion — meaning their retention was hashes without signatures, which is not the same evidentiary weight, and their compliance auditor caught the gap.

Cross-border verification: signatures are what carry the weight. A hash produced in one jurisdiction and stored in another jurisdiction has no independent verifiability across the border unless there is a trust framework that binds the two. A signature under eIDAS Article 26 AdES carries its own trust framework in the certificate chain, which resolves against the EU Trusted List or its equivalents. This is the mechanism that makes global digital identity workable in cross-border contracting: a Filipino founder signing a services agreement with a Berlin fintech, or a Colombian exporter signing a shipping document consumed by a Rotterdam port authority, produces a signature whose trust chain is verifiable in both jurisdictions. Hashes cannot make that claim on their own.

How do the two combine in real signature standards — PAdES, XAdES, CAdES?

They combine because signature standards are, at their core, structured envelopes that carry a hash, a signature over the hash, a certificate for the signer, and validation data — all in a format that the verifier can consume.

The three ETSI-standardised AdES profiles map to three document/data formats. PAdES (ETSI EN 319 142) covers PDF documents; the signature is embedded inside the PDF as an incremental update, with the hash computed over the pre-signature document bytes. XAdES (ETSI EN 319 132) covers XML documents; the signature is embedded as an XMLDSig-based structure with additional AdES-specific properties. CAdES (ETSI EN 319 122) covers CMS-based data (typically binary payloads); the signature wraps the data in a Cryptographic Message Syntax envelope. All three profiles share the same underlying architecture: hash the payload with SHA-256 (or higher), sign the hash with the private key, embed the signature alongside the signing certificate, and add the validation data — revocation status, timestamp, certificate chain — that the verifier will need at stage 3-5 of the ETSI EN 319 102-1 validation procedure covered earlier.

The pattern I've watched work best is to treat the hash and the signature as two layers of the same architectural decision rather than as competing alternatives. Every deployment produces hashes as a side effect of signing; the operational question is whether the deployment also retains the signature and certificate, or discards them and keeps only the hash. A Zurich-based financial-messaging platform we worked with in early 2026 had exactly this decision to make: their inbound message flow produced a hash for internal integrity, but their outbound to counterparties needed a signature for downstream authenticity. The correct architecture wasn't one or the other; it was a hash pipeline for internal integrity and a signature pipeline for outbound authenticity, sharing the same hash step and diverging at the private-key transformation.

The way we architect this at IdentiGate is by treating the hash as the shared foundation of every integrity check and the signature as the layer that adds authenticity when the deployment needs it. The Identity Verification product produces a chip-anchored proofing record — passport NFC chip read for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country — that binds the signing certificate's subject to a verified person. The Signatures product produces the AdES signature under eIDAS Article 26, which contains the hash as its integrity primitive and adds authenticity through the identity binding. The Evidence Layer product retains the full envelope — hash, signature, certificate, validation data, proofing evidence — in a form that a verifier at month forty-eight can consume without needing to trust any commercial party's assertion. The hash is the foundation; the signature is what makes the foundation defensible outside the organisation that produced it.

Where I disagree with the loud engineering position that "just hash everything" is a sufficient audit strategy is that it treats every integrity property as equivalent. It isn't. Internal integrity — the system checking whether its own data has changed — is well-served by hashing. External authenticity — the counterparty, auditor, or regulator checking who produced the data — requires signatures. The two are not substitutes. Getting the architecture right means recognising which property the specific data flow actually needs and applying the correct primitive rather than defaulting to the cheaper one across the board.

Sources

Primary — eIDAS and signature framework

Primary — ETSI signature standards

Primary — IETF cryptographic standards

Primary — NIST cryptographic standards

Primary — identity assurance and document standards

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.