Imagine a question asked by a photographer, an archivist or a rights holder:
“I’ve had this TIFF since 2018. How do I show that it still matches, exactly, the file that was archived back then?”
The question sounds simple. It isn’t, because it contains several: has this file changed? Compared with what? Who says so? Since when? And how can someone else check, without having to take my word for it?
This final article in the series works through those questions one by one. Each step adds something to the previous one, and each has limits worth knowing.
1. The fingerprint: describing a file unambiguously
The starting point is the SHA-256 fingerprint, introduced in the first article of the series: a 64-character string computed from the entire content of the file. The same file always gives the same fingerprint; the slightest change gives a different one.
A fingerprint identifies a file exactly. Saying “the TIFF whose fingerprint is 3a7f…” means that content and no other, whatever its name or wherever it is stored.
What it doesn’t say: on its own, a fingerprint has no date and no author. If you compute it today, it describes today’s file. To prove the file has not changed since 2018, you need a fingerprint recorded in 2018, and a reason to trust that record.
That is an honest limit worth stating right away: no tool can prove, after the fact, the state of a file on a date when nobody recorded its fingerprint. The proof starts on the day the fingerprint is taken. The best time to take it was the day of archiving; the second-best time is today.
2. The fixity check: comparing over time
A reference fingerprint is only useful if you compare against it. That is the fixity check: read the file in full, recompute its fingerprint, compare it with the reference.
In Obscura Vault, each file’s fingerprint is taken at import, then compared at every audit, on demand or scheduled weekly or monthly. Each check is added to the fixity log, with its date, result, the expected fingerprint and the one observed; a check never overwrites an earlier one. The file is then Verified, Altered, Unverifiable (missing or unreadable: nothing is proven either way) or Never Checked. See Fixity checks.
What it doesn’t say: that log lives in your library. It convinces you. To convince someone else, you have to give them something they can check for themselves.
3. The digital signature: making the statement tamper-evident
A digital signature is computed over a document with a private key that only the signer holds. Anyone can then check it with the matching public key. If a single character of the document changes, the signature no longer matches.
Obscura Vault signs with Ed25519, a public algorithm described in RFC 8032. It already signs the manifest of every .obf archive, which lists each file’s fingerprint: that is how you can check an archive has not moved since it was created (see The .obf format).
What it proves, exactly: that the document has not been modified since it was signed, and that it was signed by the key matching a given public key.
What it does not prove: who is behind that key. A signature ties a document to a key, not to a person. To know the key really belongs to the issuer you think it does, you need another piece of information: for instance, that the public key is published on a website you know to be theirs.
4. The date: declared, or attested by a third party
That leaves the date. A signed document can carry a date, but that date is written by the signer. It is protected against change, since it is signed; it is not, for all that, attested by anyone else.
There is a standard way to have a date attested by a third party: an RFC 3161 timestamp. A timestamp authority issues a token attesting that a signature existed at a given moment.
In Obscura Vault this is optional:
- with no timestamp authority set (the default), no network call is made, and the certificate itself prints that its date is declarative;
- with an authority set, each issuance asks it for a token. If the authority does not respond, issuance fails, rather than quietly producing a weaker certificate.
5. The preservation certificate: bringing it together in one document
The preservation certificate brings these steps together in a document you can hand to someone else. It is a PDF/A-2b, the variant of PDF intended for archiving, with an embedded manifest signed with Ed25519.
For a file, it attests among other things: the project, the file’s path within its project, its size, its SHA-256 fingerprint, its latest fixity check, and the archives that contain it. For an archive, it attests the package fingerprint, the number of files and the fingerprint of their list, the latest verification, the known locations and the offsite copies. It carries a number, a version, an issue date, the issuer’s name, the address where the issuer publishes their public key and, if there is one, the timestamp token. Since version 1.2, an incremental revision (which holds only what changed) also gets a certificate, attesting the complete state of the project at that revision.
An absence is written and signed, never left blank: a file that was never checked can be certified, but the certificate says so (“no check recorded”). And Vault refuses to certify a file whose latest check did not match.
Back to the 2018 TIFF. If its fingerprint was recorded when it was imported into Vault, and checked since, a certificate issued today states, signed: here is this file’s fingerprint, here are the date and result of its latest check. In five years, a new certificate, or simply recomputing the fingerprint, can be compared with this one. The chain of proof starts with the first record, and grows stronger with each check.
If the TIFF only entered Vault in 2026, the proof starts in 2026, not 2018. To go further back, you need a fingerprint recorded at the time: the manifest of an archive signed back then, for example, which gives the file’s fingerprint and a creation date, itself declared by whoever wrote it.
Details are on The preservation certificate page and in the Preservation certificates chapter of the user guide.
Verifying a certificate without trusting the issuer
A certificate is only worth something if the person receiving it can check it without asking the person who issued it. There are two ways to do that.
On the web. Every certificate prints an address and a QR code of the form vault.obscuraflow.app/c/<number>/<version>. The recipient opens the verification page and drops the PDF onto it. The file is read by their browser, in memory: it is not sent anywhere. The page checks the Ed25519 signature, that the key appears in the file the issuer publishes at the address written in the certificate, and that the signed number and version match the address. It answers with one of five results: valid, invalid signature, unreadable certificate, unknown key, unsupported version.
It also says what it does not check: the issuer’s register status (superseded, revoked) is shown as “unknown outside the register”; a timestamp is reported if present, but not validated; and “valid” means “signed by the key this address publishes”, not “the issuer’s identity is proven”.
Offline, in Obscura Vault. Verify a PDF… works without a network, on a certificate issued by any installation, and it is free. Vault gives a verdict on the signature, the revocation status when the certificate is in its register, whether the printed text matches the signed values, the timestamp status and, for an archive, whether the annex matches.
For an archive certificate, the list of files is delivered next to the PDF, as an annex. Anyone can check it with an ordinary checksum tool (shasum -a 256 on the annex file): the result must be the fingerprint printed on the certificate.
What a certificate does not say
For proof to be useful, you need to know where it stops. A preservation certificate:
- attests what the issuer’s library knows about the object at the time of issue. It says nothing about what the image shows, or who made it;
- describes a state at a date, not beyond: what happens to the file afterwards is a matter for later checks;
- has a declarative date, unless an RFC 3161 timestamp was requested from a third-party authority;
- is not, by itself, legal proof. The signature proves the certificate comes from a given key and has not been changed. The weight it carries in a contractual or legal setting depends on that setting, on the trust placed in the issuer, and on the rest of the evidence.
These are limits, but they are written down, and that is what makes the document credible. A certificate that claimed to prove everything would prove nothing.
Who it is for
A few situations where a preservation certificate can be useful:
- a photographer delivering files to a client or an agency, who wants to be able to show later that the archived original has not moved;
- an archive service or institution that receives or holds a collection and has to account for its integrity;
- rights holders who inherit a body of work and want to pass on, with the files, the means to check their state;
- a collection or heritage fund that moves between lenders, insurers and storage sites.
Issuing a certificate requires a licence; verifying one is free, in the app as on the web.
End of the series
These four articles followed one thread: a digital file does not wear out, but it can change; three copies are not enough if you don’t know they are good; an archive must be openable without the software that created it; and a photograph’s integrity can be proven, provided you say exactly what is being proven.
That is what Obscura Vault sets out to do: verify, and say exactly what was verified. To go further: the documentation, the features, the glossary and the FAQ.
Previous article: In 20 years, will anyone still be able to open your photo archives?
Start the series from the beginning: A digital file doesn’t wear out. So why check its integrity?