In 20 years, will anyone still be able to open your photo archives?

Twenty years is not long in the life of a photograph. A print from 2006 can be looked at without any trouble. A negative from 1986 can be scanned. But a file from 2006, stored at the time in the format of software that no longer exists, can be harder to open than a forty-year-old negative.

The first two articles in this series were about integrity: making sure a file’s bytes have not changed, and that your copies are good. This one asks a different, more insidious question: even intact, will your archives be openable, and by whom?

It is a question of handing things on. For a photographer thinking about their heirs, a studio changing tools, an association or institution that takes in a collection and will have to look after it long after the people who built it have gone.

What makes an archive unreadable

An archive can become inaccessible without a single byte being damaged. The causes are well known.

Dependence on software. Many tools store files in a container of their own, which only they can open. As long as the software exists, all is well. The day it is no longer updated for the current operating system, the archive becomes a closed box.

Opaque formats. A format whose description has not been published can only be read by those who know it. If nobody documented it, nobody will be able to write the program that reads it tomorrow.

A vendor disappearing. Companies close, get bought, drop products. An archive that only makes sense inside one vendor’s application shares that vendor’s fate.

Passwords and encryption. An encrypted archive is protected from prying eyes, and also from its own heirs if the key was never passed on. Encryption is unforgiving: without the key, there is no back door.

Missing documentation. Even with open formats, you need to know what the archive contains, how it is organised, and in what order to do things to restore it. If that knowledge lives only in one person’s head, it leaves with them.

One simple idea

These risks lead to one principle:

A truly lasting archive should not depend on the survival of the software that created it.

That does not make the software useless. It makes day-to-day work safer and simpler: checking, scheduling, sending, restoring. But on the day it is gone, the archive must remain understandable with ordinary tools and public descriptions.

What is inside an Obscura Vault archive

Obscura Vault stores each project in an .obf archive. It is not a closed file: it is a folder, holding files in open formats and a readable inventory.

• The content: the whole project folder, in a tar archive compressed with zstd (the default; tar.gz, uncompressed tar and zip are also offered).
• The manifest (manifest.json): the inventory, in JSON, a text format readable in any editor. It lists every file with its path, size and SHA-256 fingerprint, along with the content’s fingerprint, the creation date and the software that wrote it.
• The signature (signature.ed25519): an Ed25519 signature of the exact bytes of the manifest.

Each of these building blocks is a public standard, described in a text anyone can read:

The .obf format itself is not new: it is the format of Obscura Flow 2.0.8, unchanged. Vault keeps archives written by Flow as proof of compatibility, and every version of Vault checks that it can still read them, verify their signature, decrypt them and restore them identically. Details are on The .obf format page and in the user guide’s chapter The .obf format.

Without Obscura Vault: exactly what is true

It would be easy to write “your archives open without us”. That is partly true. Here is precisely what is possible today, according to the user guide.

An unencrypted archive remains usable with a Mac’s standard tools:

• read the inventory: open manifest.json in a text editor;
• check the content: in Terminal, shasum -a 256 on the content file must give the manifest’s payloadChecksum value;
• extract the files: the content is an ordinary tar, tar.gz or zip archive, and the tar that ships with macOS can read a .tar.zst archive;
• check each extracted file: shasum -a 256 on a file must give the fingerprint the manifest lists for it.

In other words: without Vault, you get your files back and you can prove, file by file, that they are the ones that were archived.

Verifying the signature by hand is possible, but requires a tool that can verify an Ed25519 signature, and the archive’s public key (Vault exports it, and that file is not secret).

An encrypted archive requires its encryption key and a program that knows how the encrypted content is laid out (4 MiB blocks, each one authenticated). A Mac’s standard tools do not do that out of the box. Today, then, an encrypted archive is restored with Obscura Vault, or with Obscura Flow, which reads the same format. This is not a hidden flaw: it is the price of encryption, and the reason it is optional.

Encryption cuts both ways

Encrypting an archive makes it unreadable to anyone without the key. That is useful for a copy left with an online storage provider, or for sensitive images. But it also means accepting a rule with no exception: lose the key, lose the archive. The user guide says it plainly: there is no way to recover an encrypted archive without its key, for anyone.

Vault manages that risk rather than hiding it:

• the keys are kept in the Mac’s keychain, not in the library: a database backup does not contain them, and losing the Mac without having exported them means losing them;
• each key can be exported to a file encrypted with a passphrase of at least 12 characters;
• as long as your keys have not been exported, Vault reminds you, and the dashboard does not report Everything Is Verified without exported archive keys.

Encryption only covers the content. The manifest and signature stay readable: you can verify an encrypted archive without its key, but not restore it.

The signing key, for its part, opens nothing: losing it makes no archive unreadable. But on another Mac that does not know it, your archives would be “unverifiable” and refused for restore until its public key has been imported. Here too, exporting is enough. The Keys and security chapter of the user guide covers each case.

Handing on, not just keeping

A lasting archive is one that someone else can take over. A few habits help, with or without Vault:

• Choose encryption knowingly. An unencrypted archive, kept on a drive you control, is easier to hand on. Encryption is mainly justified for copies entrusted to a third party.
• Export keys as soon as they are created, keep at least two copies in two places, never in the same folder as the archives, and never send them by email. Keep the passphrase apart from the file.
• Write down where things are. Where the drives are, where the offsite copies are, where the key files are, who knows the passphrases. A clear note, kept where your family or successors will find it, beats the best memory.
• Keep the documentation with the archive. A copy of the format description next to the drives costs little, and answers in advance the question “how do you open this?”.
• Test a restore from time to time, into a separate folder: it is the only way to know the keys and instructions are the right ones.

One last point, for completeness: Vault preserves the bytes of your files; it does not convert them. A lasting archive of RAW files keeps RAW files. Whether a proprietary image format will still be well supported in twenty years is a separate question, which you will settle according to your files (for example by keeping, next to the originals, versions in a widely documented format). The archive, for its part, ensures the original stays intact and recoverable.

What to remember

• An archive can become unreadable without being damaged: vanished software, opaque format, lost key, knowledge not passed on.
• A truly lasting archive should not depend on the survival of the software that created it.
• .obf archives rest on public standards: tar, zstd, JSON, SHA-256, Ed25519, and AES-256-GCM when you choose to encrypt.
• Without Vault, an unencrypted archive can be read, extracted and checked file by file with a Mac’s own tools; an encrypted archive requires its key and a program that knows its layout.
• Encryption protects, but losing the key means losing the archive: export your keys and say where they are.

One last question remains: on the day someone doubts that a photograph is really the one that was archived, how do you prove it? That is the subject of the final article in the series.

Next in the series: Can you prove a photographic file has not been modified?

Previous article: You have three copies of your photos. But do you know they are still intact?

• long-term archiving
• photographic heritage
• open formats
• encryption