Skip to content
Krellix

Documentation · Verify a collection

Verify a Krellix collection from scratch.

This page is the same verification procedure bundled inside every Krellix export as 07_TimestampMaterials/VERIFY.md. It's published here so opposing counsel, a reviewer, an expert witness, or a judge can see the steps without needing access to a specific export first.

Verification does not require Krellix. It uses sha256sum (any Linux or macOS terminal; Windows via Git Bash or WSL) and openssl (widely preinstalled on macOS and Linux; bundled with Git for Windows).

What you're verifying

Three things, in this order:

  1. File integrity. That every file in the export still hashes to the value recorded in the hash manifest. This catches accidental or deliberate modification after collection.
  2. Manifest integrity. That the hash of ChainOfCustody.json matches what was sent to the TSA. This catches modification of the manifest itself.
  3. Timestamp signature. That the TSA response (.tsr) is a valid signature over the manifest hash, issued by the TSA certificate in TSA.pem, at the UTC time the response records.

If any of the three fails, the collection is not defensible and should not be relied on. If all three pass, you have cryptographic evidence that the collection existed, unchanged, at the recorded time.

Step 1 — Verify file hashes

From the export root (the folder containing the numbered subfolders), run:

cd 06_HashManifests
sha256sum -c Hashes.sha256.txt

Expected output: one OK line per file in the export, with no lines reading FAILED. If any file reports FAILED, stop — the export has been altered since collection and its defensibility claims no longer hold.

For MD5 (if your downstream tooling prefers it):

md5sum -c Hashes.md5.txt

Step 2 — Verify the manifest hash

Compute the SHA-256 of the manifest and compare to the value recorded in the manifest's own timestamp.manifestDigest field:

cd ../07_TimestampMaterials
sha256sum ChainOfCustody.json

Open ChainOfCustody.json in a text editor. Find the timestamp object near the end of the file. The manifestDigest field should equal the hash you just computed.

If the two values match, nothing has modified the manifest since Krellix sealed it. If they don't match, the manifest has been edited after collection and the timestamp no longer covers the current contents.

Step 3 — Verify the TSA timestamp signature

The .tsr file is a PKCS#7 signed structure. OpenSSL can verify it against the TSA certificate chain captured at timestamping:

openssl ts -verify \
  -data ChainOfCustody.json \
  -in   manifest.tsr \
  -CAfile TSA.pem

Expected output: Verification: OK. Anything else means either the TSA token does not cover the current manifest hash, the TSA certificate chain is broken, or the .tsr file has been tampered with.

Extract the signing time

To read the UTC time the TSA issued the signature — the moment the collection was sealed — run:

openssl ts -reply -in manifest.tsr -text | grep "Time stamp"

This prints the exact genTime from the TSA response. That time is what opposing counsel would have to dispute if they wanted to challenge when the collection occurred.

Walking through manually in a hearing

If you need to do this in front of a judge or an expert, the short script is:

  1. Mount the export. Show the seven folders exist and are named as the documentation describes.
  2. Run sha256sum -c Hashes.sha256.txt. Show the OK lines.
  3. Run sha256sum ChainOfCustody.json and show the output matches the manifestDigest field inside the JSON.
  4. Run the openssl ts -verify command and show Verification: OK.
  5. Run openssl ts -reply to show the genTime — the third-party attested timestamp.

The entire walkthrough is four commands. The foundation-witness time per collection is about two minutes.

Common questions during verification

“What if the TSA certificate has been revoked?”

RFC 3161 timestamps are designed to remain valid even after the signing certificate is revoked, as long as the revocation happened after the timestamp was issued. The TSA provides a CRL or OCSP response that a verifier can use to confirm the cert was valid at genTime. The timestamp token embeds the certificate chain, and TSA.pem was captured at timestamping — so everything you need for revocation-aware verification is in the export, not fetched from the TSA later.

“What if the collection used a different TSA?”

Krellix defaults to DigiCert and falls back to Sectigo and GlobalSign if DigiCert is unavailable. The TSA used is recorded in ChainOfCustody.json under timestamp.tsa, and TSA.pem contains the certificate chain for whichever TSA actually signed the token. The verification commands are identical regardless of which TSA is involved.

“Can I re-verify this ten years from now?”

Yes, if you still have the export folder. The hash algorithms (SHA-256 and MD5) will still work. The TSA certificate chain in TSA.pem will still verify the timestamp token — that's the point of capturing the chain at seal time. The only long-term risk is a future cryptographic break of SHA-256, which would be a problem for the entire industry, not specifically Krellix.