Can one timestamp cover several files?

How can one fingerprint represent several files?

A timestamp binds a cryptographic fingerprint to a time. The data represented by that fingerprint can be a single file or a collection. There are several ways to construct it:

• An archive: put the files into a ZIP or another archive and timestamp the archive’s fingerprint. Verification starts with that exact archive, so preserve it rather than relying on recreating it later.
• A list of file fingerprints: calculate each file’s hash, then combine the hashes using a defined order and format and hash the result. A manifest can also record filenames and other context, provided the manifest itself is covered by the timestamp.
• A hash tree, often called a Merkle tree: combine file fingerprints in successive layers until one final fingerprint remains. That final value represents the collection, while a supporting proof can connect an individual file to it.

The method must be documented so an independent reviewer can repeat the calculation. Simply listing filenames on a certificate does not cryptographically connect their contents to the timestamp.

What does the shared date tell you?

It provides a common point by which the covered versions existed. For example, a design drawing, a prototype photograph and a test report can be included in one dated record of a development milestone, even if they were produced on different days.

The shared timestamp does not establish the order in which those files were created or prove that they belong to the same development process. Preserve the descriptions, revision references and other context that explain their relationship. If the sequence matters, create dated records at successive milestones rather than relying only on a final collection.

Can you verify one file without sharing all the others?

That depends on the method and the proof you retain. A Merkle-tree proof can provide the intermediate hashes needed to connect one file to the timestamped value without disclosing the other files. RFC 4998 describes this approach for evidence records.

With other methods, verification may require the original archive, the complete manifest or the other file fingerprints. Check the actual verification procedure before assuming you can disclose only one file. A certificate covering a collection does not automatically provide a separate, self-contained proof for each item.

What happens when you add or change a file?

The existing timestamp continues to cover the original set of file versions. It does not extend to a later addition or an edited version merely because the file sits in the same project or folder.

Create a new timestamp for the updated collection and retain the earlier version with its proof. This produces a sequence of dated records while preserving the ability to verify each milestone on its own.

What should you keep with the timestamp?

Keep the exact files or archive that were covered, the timestamp proof, and the instructions and supporting data needed to reproduce the combined fingerprint. Depending on the method, this may include a manifest, the ordering rules or an individual file’s Merkle proof.

Test the exported evidence before relying on it. A missing file or a missing step in the connecting proof can prevent verification even when the timestamp itself remains valid. See which files and context to keep alongside a timestamp certificate for the broader evidence package.