Why hashes prove things

A lot of Haubot's trust story rests on the word "hash". This article is the plain-English version of what that means — for buyers, sellers, and anyone wondering why we keep showing 64-character strings in the UI.

The 30-second version

A hash is a fingerprint of a file. You give the algorithm a file (or a JSON document, or any sequence of bytes), it returns a 64-character string. Two facts make this useful:

1. Same input, same output. If you and I both run SHA-256 on the same PDF, we get the same fingerprint, byte-for-byte.
2. Different input, wildly different output. If I change one comma in the PDF, the fingerprint changes completely. There's no "close to the original" — it's match or mismatch.

That's it. The whole trust apparatus on Haubot grows out of those two properties.

What a hash proves and what it doesn't

A hash proves: the bytes you're holding are exactly the bytes that produced this fingerprint. If the listing page says the inspection report has SHA-256 abc123…, and you download the file and compute SHA-256 yourself, and you get abc123…, then nothing has been altered between upload and download. Not a punctuation mark.

A hash does NOT prove:

• Who created the file. SHA-256 is a fingerprint, not a signature. Anyone can compute the hash of any file. The fact that the seller's hash matches your file just means you have the same bytes — not that the seller authored or vouched for them.
• Whether the file's claims are true. A faked inspection report has its own hash; the math doesn't care if the contents are honest.
• When the file was created. Hashes have no time concept. We pair them with platform-recorded timestamps in our audit log to give "this hash was first observed at this time", but that's our timestamp, not a hash property.

So when you see a hash on Haubot, treat it as: "This is what the platform attests to. If I download and re-hash, I can prove the file matches. Whether the document is honest is a separate question — that's why we also have inspections, escrow, audit logs and reputation."

Why we keep showing them

Three places in the platform display hashes:

Per-file content hash

Every file in a UnitVault has a SHA-256 we computed on upload by streaming the bytes through our hashing service. The hash is recorded in the database alongside the storage key. Buyers see a short version of the hash in the file's Details panel, with a copy-full button.

This lets a buyer verify months later that the file they downloaded is byte-identical to the file the seller uploaded.

Snapshot manifest hash

A snapshot is a frozen record of the entire vault on a specific date. We build a canonical JSON listing every file (with its content hash) plus the snapshot's metadata, and SHA-256 the JSON. That's the manifest hash. Buyers see it on the listing's trust panel.

This lets you verify the whole document set hasn't changed since snapshot time — not just any one file. Edit a file or add a new one to the live vault, and the next snapshot's hash will be different.

Filtered package hash

When a buyer downloads a package ZIP and they're not seeing every file (some are restricted), the ZIP includes a filtered_manifest.json with its own hash. The README explains both that hash and the original snapshot hash, with instructions for verifying both.

The math, briefly

SHA-256 is a member of the SHA-2 family, designed in 2001 by the NSA, standardised by NIST. It produces a 256-bit output, conventionally written as 64 hexadecimal characters. The algorithm has the property that finding two different inputs with the same hash (a collision) is computationally infeasible — well past the resources of any actor on Earth at current technology.

Practically: every file in our vault has a unique hash. If two files have the same hash, they're identical. There's no need to second-guess this.

How to compute a hash yourself

You don't need any special software. Three quick recipes:

macOS / Linux:

shasum -a 256 inspection-report.pdf

Windows PowerShell:

Get-FileHash -Algorithm SHA256 inspection-report.pdf

Online tool (last resort):

We don't recommend pasting confidential documents into random web tools. If you must, use a reputable hosted hasher and confirm the URL is HTTPS. Better to install a local tool — it takes 30 seconds.

The output is a 64-character hex string. Compare it to whatever the platform showed.

What's coming after hashes

Hashes prove integrity. The next step in the trust ladder is non-repudiation — proving that Haubot itself attested to a value, not just that the bytes match. That requires cryptographic signatures, key management, and rotation.

Today, the trust anchor is the hash plus the audit log: every export, view and verification is logged with timestamps and the actor's ID, so even without a signature, the path from "what was disclosed" to "what you have now" is reconstructable.

A future phase will add server-side signatures over manifest_hash. We've intentionally left it for later because key management is its own design problem and we'd rather get it right than ship something we'd have to redesign.

Why this matters in practice

When a buyer asks "are you sure this is the same report I saw at the time of bid?", you can answer yes with maths, not with a promise. When a seller is asked the same six months after a transaction, the hash plus the snapshot date plus the audit log produce a single coherent answer. That's worth more than another spec sheet field.