Two Jobs, One Setting
Every professional offload tool computes a checksum for each file it copies. OffShoot, Silverstack, ShotPut Pro and YoYotta all do it, and all of them write the results into a manifest next to the copied files. The setting that controls which checksum they use sits in the preferences, and most people never open it.
That is fine as long as the checksum has one job: catching copy errors. Any checksum does that well, and the fast ones do it with the least waiting. It stops being fine the moment the checksum gets a second job, which is proving what the files contained. Evidence photography, documentation for insurers or authorities, and any shoot that may end up in a dispute all put the checksum in that second role. The default setting cannot fill it.
Why the Defaults Are Not Enough
The common default is xxHash, and the reason is honest: it is extremely fast, and for detecting transfer errors it is exactly the right tool. But xxHash is not a cryptographic hash. Given a target value, constructing a different file with the same xxHash is feasible. A checksum list built on xxHash therefore proves that a copy operation happened and succeeded. It cannot prove, against a determined challenge, that the files on disk today are the files the list described.
MD5 and SHA-1 look more respectable because they were designed as cryptographic hashes, but both have publicly known collision attacks. Two different files with the same MD5 can be produced on ordinary hardware. In a context where someone is paid to find weaknesses in your records, an MD5 manifest invites the same objection as an xxHash one.
The practical consequence shows up when a manifest gets anchored. When Lumethic timestamps an offload manifest, the receipt is graded by what the checksums can support. A manifest built on xxHash, MD5 or SHA-1 earns an offload-event-only grade: the anchor proves the backup took place no later than the anchor date, and nothing about the contents. A manifest built on C4 earns the content-bound grade, where the anchor covers what every file contained. The card offload receipts page explains the two grades in detail.
What C4 Is
C4 is the content-addressing checksum defined alongside the ASC Media Hash List standard, the manifest format maintained by the American Society of Cinematographers for professional media workflows. Internally a C4 ID is built on SHA-512, a cryptographic hash with no known collision attacks, encoded into a fixed-length identifier that always starts with "c4".
For the purpose of this article, two properties matter. A C4 value binds file contents: producing a different file with the same C4 ID is not feasible with any known technique. And C4 is part of the same standard your offload tool already implements for MHL manifests, so choosing it does not take you outside normal, documented industry practice. That second point has weight in a dispute. You are not defending an exotic homegrown procedure, you are pointing at the checksum option of a published standard.
The cost is speed. C4 is slower to compute than xxHash. On a modern laptop the difference during a card offload is minutes, not hours, and it buys the difference between "a copy happened" and "these exact contents existed".
Changing the Setting in Your Tool
The checksum type is a per-tool preference, not a per-transfer choice, so this is a one-time change.
In OffShoot, xxHash64 checksums are always generated; C4 is enabled in addition, in the transfer preferences, where OffShoot groups it with the other non-default checksum types. Turn it on and every subsequent transfer records C4 values in the manifest alongside the xxHash entries. The extra entries are what matters: the anchor grade rests on the strongest content-binding checksum the manifest carries.
In Silverstack, the hash type is chosen in the offload settings. Silverstack supports several hash formats side by side; make sure C4 is the selected type before the backup runs, because the hash is computed during the copy.
In ShotPut Pro, the checksum type is set in the preferences under verification. Pick C4 as the algorithm and leave verification enabled, so the tool reads the copy back and confirms the values it wrote.
Menus move between versions, so treat the tool's own documentation as authoritative for where the option lives. The check that matters comes afterwards and takes ten seconds: open the manifest your tool wrote and look at the hash entries. C4 values are unmistakable, every one begins with the letters "c4". If you see short hexadecimal strings instead, the tool is still on a speed checksum.
One more habit belongs to the same change. Compute the checksum from the card, not from the copy. All the tools above do this correctly during a normal offload, but it is worth stating: a hash list generated later from working copies proves nothing about the card. The manifest has evidential value precisely because it was written at the moment of the first backup.
What Changes in the Manifest
Nothing about your workflow changes after the switch. The tool still writes an MHL manifest, hashdeep output or its own hash list next to the copied files. The entries inside simply carry C4 identifiers instead of xxHash values.
What changes is what that file can do. A C4 manifest is a complete, tamper-evident fingerprint of the card at the moment of backup. Anyone holding the manifest can later recompute the C4 ID of any file and confirm it is byte-for-byte the file the backup saw. That check works with open tools, independent of the transfer software and independent of Lumethic.
The Step After the Checksum
A C4 manifest on your own disk still has the weakness our chain of custody guide describes: nothing outside your own records fixes its date. The list is strong, the timeline is not.
Anchoring closes that. Upload the manifest and Lumethic signs it and has it countersigned by an independent timestamp authority. The resulting receipt states that this manifest, and with it the fingerprint of every file on the card, existed no later than the anchor date, and anyone can check it on the public receipt checker without an account. With C4 checksums underneath, the receipt carries the content-bound grade, which is the version you want if the shoot ever faces scrutiny.
If you photograph for legal or documentation work, the camera setup checklist covers the settings that matter before the shoot, and the legal evidence workflow shows where the anchored manifest sits in the path from card to exhibit.
Checksum FAQ
Does switching to C4 slow down my offloads? It adds computation time compared to xxHash, typically minutes on a full card with current hardware. Transfer time is usually dominated by the card reader and destination drive, not the hash.
Should I re-hash old shoots with C4? You can, but the result proves the state of your working copies today, not the state of the card on the shoot date. It is still worth doing for material that matters, and worth anchoring, because it at least fixes today as a bound. For future shoots, the manifest written during the offload is the one with real weight.
My tool offers SHA-256. Is that acceptable? SHA-256 is cryptographically sound and binds contents. If your tool offers it inside a standard manifest format, it serves the same purpose. C4 has the advantage of being the content-binding option defined in the ASC MHL standard itself, which keeps the whole manifest inside one published specification.
Do I need a different tool? No. OffShoot, Silverstack, ShotPut Pro and YoYotta are the standard tools in professional film and photo work, and all of them can write manifests suitable for anchoring. The change is one preference, not a new workflow.
