What is a document hash and how does it help prove its integrity?

A hash is a digital fingerprint calculated from the exact contents of a file. If a single byte of the PDF is changed, the result normally changes completely. This property lets you check whether a stored file is exactly the same one that was recorded at an earlier point in time.

For example, a system can calculate the SHA-256 of the original PDF, record it, generate the final document with the signatures, and calculate a second hash of the signed PDF. Later, the hash of the submitted file is recalculated and compared against the stored value.

What does a match prove?

If the recalculated hash matches the recorded hash, you can state that the bytes of the verified file match those of the file used to generate that record.

This provides very useful evidence of integrity: the document has not changed compared to the reference copy. It also allows accidental or deliberate modifications to be detected.

What can't a hash prove on its own?

A hash does not by itself answer these questions:

• Who signed the document?
• Did the person understand and accept the content?
• When was the hash actually calculated?
• Who controlled the database where it was stored?
• Had the record already been tampered with before verification?
• Did the signer have sufficient capacity or authority to sign?

It is also possible to edit a PDF and generate a new hash of the altered file. The hash does not prevent this action. What it allows is detecting that the new file no longer matches the reference value stored beforehand.

That's why it's important for the reference value to be protected, linked to a timestamped event, and included in an audit log with access controls.

Original hash and final hash

In a signing flow, it's useful to distinguish between:

1. Hash of the original document. Identifies the PDF before signatures are collected.
2. Hash of the final document. Identifies the complete PDF after signatures, verification data, or an evidence certificate have been added.

It's normal for the two to differ: adding a visible signature, an evidence page, or metadata modifies the file and, therefore, changes the hash.

The correct chain is to keep both and document the relationship between them. This makes it possible to prove which original started the process and which final document resulted from it.

Does a QR or verification code replace the hash?

No. The QR is a practical way to reach a verification page. It can contain a URL and an opaque code that allow the record to be looked up, but it is not the cryptographic proof itself.

A good verification page can show:

• document status;
• creation and completion dates;
• verification code;
• hash of the final document;
• whether the file the user uploads to verify matches or not;
• key signing events, respecting privacy;
• a clear notice if the document has expired or been revoked.

The code should not be sequential or easy to guess. Personal data, full IP addresses, or the downloadable document should not be exposed publicly without assessing permissions, expiry, and confidentiality risks.

Audit log: the pieces that provide context

A hash gains strength when it's integrated into a coherent record:

• unique process identifier;
• document and version shown;
• original and final hash;
• date and time of events;
• recipients and channels used;
• viewing, acceptance, signing, or rejection actions;
• authentication method;
• version of the consent texts;
• retention and deletion policy;
• controls to prevent silent alterations to the record.

An IP address is contextual data, not infallible identification. If it's stored, the need for it must be justified, it must be protected, and GDPR principles must be applied, including minimization and limiting the retention period.

Hash versus cryptographic digital signature

Storing a hash in a database is not the same as applying a certificate-based digital signature to the PDF. A cryptographic digital signature links the document to a key and allows integrity and other properties to be validated through public key infrastructure.

In an SES, the hash can be used as additional evidence without claiming that the PDF contains an AES or QES. This distinction must be explained transparently.

Best practices for Sygnau

• Use a current algorithm such as SHA-256 or higher, in line with applicable technical recommendations.
• Calculate the hash on the server over the exact bytes that will be stored or delivered.
• Never silently recalculate and overwrite the reference hash.
• Keep an append-only history or one with equivalent protections.
• Show, at verification time, which file is being checked and against which record.
• Separate the public verification code from internal identifiers.
• Log revocations or incidents without deleting the history.
• Apply expiry, download authorization, and data minimization.

Sources

• Requirements for advanced electronic signatures, Article 26 — eIDAS
• Signature validation and integrity — European Commission
• General Data Protection Regulation — EUR-Lex

---