INTEGRITY DESK / FIELD GUIDE / 001

A HASH PROVES BYTES, NOT TRUTH.

SHA-256 can tell you whether two byte sequences match. It cannot tell you whether the file is authentic, safe, complete, honest, current, or even the file you meant to acquire.

Cyberdelia Archive + Software Operations.

THE USEFUL THING

Cryptographic hashes are excellent at byte identity.

A cryptographic hash function maps an input of arbitrary length to a fixed-size digest. With SHA-256, the digest is 256 bits. Change the input and, with overwhelming probability, the digest changes too.

That makes hashes extremely useful for integrity work. If Cyberdelia acquires a file, records its SHA-256, and later recomputes the same digest from the preserved bytes, we have strong evidence that the file has not changed since the recorded hash was created.

This is exactly why archive manifests, software packages, source mirrors, and research artifacts should carry hashes. Byte identity is foundational.

The failure begins when people ask the hash to prove things it was never designed to prove.

THE LIMIT

A perfect checksum of the wrong file is still the wrong file.

Suppose you download a document from a compromised mirror. You compute SHA-256 immediately and preserve the digest forever. Every later verification succeeds.

Congratulations: you have proven that your bad copy remained faithfully bad.

The hash does not know whether the acquisition source was legitimate. It does not know whether a malicious actor replaced the file before you arrived. It does not know whether the filename was misleading, the server was compromised, the package was incomplete, or the document was fabricated upstream.

Integrity begins after acquisition identity. Authenticity and provenance require additional evidence.

FOUR DIFFERENT QUESTIONS

Stop compressing evidence into one word.

People often use “verified” to mean several different things. Cyberdelia separates at least four questions:

Integrity: Are these bytes unchanged relative to a known digest?

Authenticity: Is there good evidence the object came from the claimed author, publisher, device, institution, or signer?

Provenance: Can we reconstruct where the object came from, when it was acquired, by what route, and what transformations occurred afterward?

Truth: Are the claims inside the object accurate?

A hash directly helps with the first. It can support the others, but it does not collapse them.

KNOWN HASHES

A checksum is strongest when the expected value has an independent source.

If a software project publishes a SHA-256 digest over one channel and you acquire the package over another, matching the two can provide useful evidence that the package you obtained is the package the publisher expected.

If the file and its checksum arrive from the same compromised location, an attacker who can replace one may be able to replace both. Matching values still prove internal consistency, but the independence of the evidence is weaker.

That is why release signatures, authenticated repositories, transparency systems, independent mirrors, package-manager metadata, and multiple authoritative records can matter. The goal is not to collect ceremonial hashes. The goal is to anchor byte identity to a trustworthy acquisition story.

DIGITAL SIGNATURES

A signature answers a different question than a bare hash.

Digital signatures use public-key cryptography to provide evidence that data was signed using the private key corresponding to a known public key, while also protecting the signed content against undetected modification.

That can add an authenticity layer a standalone checksum does not provide. But signatures inherit their own trust questions: how did you obtain the public key, who controls it, can it be revoked, was the signing key compromised, what exact bytes were signed, and does the signer’s identity actually mean what you think it means?

A valid signature is strong evidence when the key relationship is trustworthy. It is not a magic certificate that every claim inside the signed document is true.

SOURCE AUTHORITY

Preserve where the object came from, not just what it became.

For public records, Cyberdelia records the source authority and source URL alongside the local mirror. A National Archives document should remain identified as a National Archives source even after Cyberdelia holds a preservation copy. A U.S. Senate hearing should remain attributed to the Senate source from which it was acquired.

The local hash tells us whether our held copy changes. The source metadata tells us what object we believed we were preserving.

Those records serve different functions and should never be collapsed into one “verified” badge.

RETRIEVAL EVENT

A download is an acquisition event, not eternal identity.

Web resources change. Vendors replace installers. Agencies correct PDFs. Projects reissue assets. Cloud storage objects get updated. Sometimes a URL stays the same while the bytes change.

Cyberdelia treats a retrieval as a timestamped event: source URL, retrieval time, original filename or identifier, content type, byte count, and hash. If the same source later produces different bytes, that is a new acquisition event.

Do not silently overwrite the older object and pretend continuity. Preserve the version relationship.

History becomes useful precisely when the present changed.

MANIFESTS

Hash files are better when machines can understand the context.

A plain SHA256SUMS.txt is valuable because common tools can verify it easily. A structured manifest adds meaning around those hashes.

Useful fields include stable object ID, title, class, source authority, source URL, original filename, retrieval timestamp, MIME type, byte count, SHA-256, license or redistribution state, local archive path, verification state, derivative relationships, transformations, and corrections or supersession history.

The checksum answers “same bytes?” The manifest answers “same bytes of what?”

DERIVATIVES

OCR is not the scan. Extraction is not the archive. Repair is not the original.

Archives produce useful derivatives: OCR text, thumbnails, transcoded media, repaired documents, extracted filesystem trees, normalized data, transcripts, summaries, redacted copies, searchable indexes, and analytical datasets.

Every one of those outputs should have its own identity and, where important, its own hash.

The source object should remain separate. A corrected OCR transcript must not silently replace the scan it was derived from. A repaired ZIP must not overwrite the damaged original if the damaged state is historically or diagnostically relevant. A cropped image is not the camera original.

Hashing both source and derivative makes transformation boundaries visible.

SOFTWARE

Checksum verification does not make code safe.

A package can match its published checksum and still contain a vulnerability, destructive bug, spyware, malicious functionality, insecure defaults, or code that is simply inappropriate for your environment.

Integrity is necessary for trustworthy software distribution, but it is not a substitute for source review, reputation, sandboxing, signatures, package-manager trust, vulnerability assessment, runtime isolation, or understanding what privileges the software requires.

Cyberdelia’s software package contract therefore records system effects and test state in addition to hashes: required privileges, network effects, filesystem effects, cleanup, known risks, origin, license, transformations, and whether the package was actually tested.

“The hash matches” means the package is the expected package. It does not mean running it is a good idea.

FORENSICS

Hashing supports chain-of-custody thinking, but documentation still matters.

In forensic and evidence-preservation workflows, a digest can demonstrate that an acquired image or exported file remains byte-identical across transfers and analysis stages. That is powerful because it lets investigators work on copies while preserving confidence in the original object’s integrity.

But a forensic hash cannot document who collected the data, under what authority, from which device, with what tool, whether the acquisition was complete, whether the source clock was wrong, or whether relevant data was omitted before acquisition.

The checksum belongs inside the evidence record, not in place of it.

COLLISIONS

Theoretical caveats belong in proportion.

Cryptographic hashes are designed to make it computationally infeasible to find two different inputs with the same digest. For modern archival use, SHA-256 remains widely used because accidental collisions are astronomically improbable and practical collision attacks against full SHA-256 are not known.

That does not mean every hash algorithm is equally suitable forever. Older algorithms can become unsuitable as cryptanalysis advances. MD5 and SHA-1, for example, should not be treated as modern collision-resistant integrity anchors for adversarial contexts.

Good archive design records the algorithm explicitly so a future system can add stronger digests without losing the historical record.

TRUST-ON-FIRST-USE

The first recorded hash creates a baseline. It does not certify the baseline.

Sometimes no authoritative checksum or signature exists. You acquire a historical file from the best available source, hash it, and preserve it.

That still has value. From that moment forward, you can detect changes to your held copy. You can compare the object against future copies. You can publish the acquisition metadata so others can reproduce or challenge the provenance.

Just label the state accurately. “Cyberdelia acquired these bytes from this source on this date and has preserved them unchanged” is a defensible claim. “This hash proves the document is authentic” is not.

PRACTICAL WORKFLOW

What to do when a file matters.

1. Identify the source. Record authority, URL, repository, device, sender, or acquisition path.

2. Acquire without unnecessary transformation. Preserve the original response or file whenever practical.

3. Record metadata immediately. Retrieval time, filename, type, size, relevant headers or release identifiers.

4. Compute SHA-256. Store it outside the file itself and in a machine-readable manifest where possible.

5. Compare independent integrity/authenticity information. Published checksums, signatures, release metadata, alternate authoritative copies, or known-good records.

6. Lock the source object. Analyze copies and derivatives.

7. Hash important derivatives too. Keep parent-child relationships explicit.

8. Reverify periodically or in CI. A stored checksum becomes operationally useful when something actually recomputes it.

9. Version change instead of overwriting it. New bytes are a new event.

10. State what the evidence proves at the correct level. Integrity, authenticity, provenance, and truth are separate claims.

CYBERDELIA RULE

Source URL + held copy + retrieval metadata + checksum.

For material Cyberdelia materially relies on, the preferred preservation chain is straightforward:

Source URL tells us where we got it.

Held copy gives us custody if the source disappears.

Retrieval metadata tells us when and how the acquisition occurred.

Checksum tells us whether our bytes later changed.

Derivatives remain separate so interpretation does not overwrite evidence.

No single piece replaces the others.

BOTTOM LINE

Hashes are powerful because they answer one question extremely well.

Use them for that question.

SHA-256 can prove that the bytes you have now match the bytes represented by a recorded digest. Everything beyond that requires context.

Good evidence systems do not weaken hashes by admitting their limits. They become stronger because every layer has a job.