Using Hashes for Verification

Using Hashes for Verification: How to Check That a File Hasn't Changed

To verify a file with a hash, you compute its cryptographic hash (for example with SHA-256) and compare the result to a trusted reference value. If the two strings match exactly, the file is bit-for-bit identical to the one the reference was made from. If they differ by even one character, the file has changed.

That's the whole idea. The details that matter are where the reference value comes from, what a match actually tells you, and what it can't tell you.

What a hash actually is?

A cryptographic hash function takes any input, whether a one-line text file or a 40 GB video, and produces a fixed-length string. SHA-256 always produces 256 bits, usually written as 64 hexadecimal characters. The algorithm is defined in NIST's Secure Hash Standard, FIPS 180-4, and RFC 6234 describes it in an implementation-friendly form.

Three properties make hashes useful for verification:

Deterministic: The same input always gives the same output, on any computer.

Sensitive to change: Alter one bit of the input and the output changes completely. This is often called the avalanche effect.

One-way: You can't realistically work backwards from a hash to the original file, and you can't realistically build a different file that produces the same hash.

You can see the second property for yourself. The SHA-256 of the lowercase word hello is:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Capitalize the first letter, so the input is Hello, and you get:

185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

Nothing about the second string looks like a small edit of the first. That's what makes tampering visible.

A hash is not encryption. Nothing is hidden and nothing can be decrypted. A hash is a fingerprint, not a locked box.

How hash verification works, step by step

The process is the same whatever the file is.

1- Get a reference hash from a source you trust. This might be the software vendor's download page, a signed release note, or a hash you generated yourself earlier.

2- Compute the hash of the file you have. Use the same algorithm the reference used. A SHA-256 value can't be compared to an MD5 value.

3- Compare the two strings. Ignore upper or lower case in the hex characters, since both are common. Everything else must match exactly.

4- Act on the result. A match means the files are identical. A mismatch means they aren't, and you shouldn't use the file until you understand why.

Computing the hash takes one command on most systems:

Windows (PowerShell): Get-FileHash .\yourfile.zip -Algorithm SHA256

macOS: shasum -a 256 yourfile.zip

Linux: sha256sum yourfile.zip

Compare the output to the published value. Pasting both into a text editor and searching for one inside the other is more reliable than comparing by eye.

Where the reference hash comes from matters more than the hash?

This is the part most short guides skip. A hash comparison only tells you the two files match each other. It says nothing about whether the reference is trustworthy.

Suppose an attacker compromises a download server and replaces both the installer and the checksum file sitting next to it. Your comparison will pass, because the attacker made sure the fake file matches the fake checksum. The check did its job, but you gave it a poisoned reference.

So the useful question is how the reference reaches you through a channel the attacker can't also control. Common answers:

* The hash is published on a different site or channel than the download.

* The hash is itself covered by a digital signature, so tampering with it can be detected.

* You computed the hash yourself at an earlier moment you trust, and you kept it somewhere safe.

The last case is the one that turns a simple checksum into something closer to evidence, and it's worth a closer look.

Verifying your own files over time

Hash verification isn't only for downloads. If you hash a contract draft, a research dataset, a design file, or a photo today, you hold a small value that can later confirm the file hasn't changed. Months later, hashing the file again and getting the same result tells you the content is identical.

There's a gap in that, though. A hash you computed and stored yourself has no independent date. Anyone can compute a hash at any time, so nothing about the string says when it was created. If you later need to show that a file existed by a certain date, "I have the hash" isn't enough, because you could have produced it yesterday.

That's why hashes are often combined with a timestamp from a source other than you.

Adding a time dimension: hashes and blockchain timestamps

A timestamping service records a hash alongside a trustworthy time. Traditional approaches rely on a time-stamping authority, as described in RFC 3161, where a third party signs the hash together with the time. Blockchain timestamping takes a different route: the hash is written into a public blockchain transaction, and the block's position in the chain provides the time reference that anyone can check.

Certelo works this way. The SHA-256 hash is calculated locally on your device, so the original file doesn't have to be uploaded just to create the record. The hash is then anchored to the Electra Protocol blockchain. Later, you can verify by hashing the file again, or by using the hash or certificate details, and checking that the same value appears in the blockchain record.

What the resulting record can support is narrow and specific: a file with this exact fingerprint existed at or before the time the record was written. That is useful. It isn't the same as proving who made the file or who owns it.

What a matching hash proves, and what it doesn't

A match proves:

> The file you have is identical to the file the hash was computed from.

> If the hash was anchored to a blockchain, the fingerprint existed at or before the recorded time.

A match does not prove:

Authorship: Anyone can hash anyone's file.

Ownership or originality: A hash says nothing about who has rights to the content.

That the content is true or lawful: A forged document hashes just as cleanly as a genuine one.

That the file is safe: A hash can confirm you received exactly what was published, including malware, if malware is what was published.

Legal admissibility: Whether and how a timestamp record is accepted as evidence depends on the jurisdiction and the case, and this article isn't legal advice. If it matters for a dispute, ask a lawyer who knows your local rules.

Hash collisions are worth a short mention. They occur when two different inputs produce the same hash. MD5 and SHA-1 are both considered broken for security purposes because researchers have demonstrated practical collisions. No practical SHA-256 collision is known, which is why it's the common choice today. If you have a choice of algorithm, use SHA-256 or stronger and avoid MD5 and SHA-1 for anything security-related.

Hashes vs. digital signatures

People often mix these up. A hash tells you whether content changed. A digital signature uses a private key to tie a hash to an identity, so it can also tell you who vouches for the content. Signatures answer "who signed this?" and hashes alone can't. The two work together: signing a document means signing its hash.

A blockchain timestamp is neither of these. It records that a fingerprint existed by a time, and it doesn't attach an identity unless you add that elsewhere.

Common reasons a hash doesn't match

When verification fails, the cause is usually mundane:

* The download was interrupted or corrupted.

* You compared different algorithms, say SHA-256 against SHA-512.

* A text file was re-saved by an editor that changed line endings or added a trailing newline.

* A document was opened and saved, which changes metadata even if the visible text looks the same.

* A zip file was re-created, which changes its internal timestamps.

* You're comparing against the hash of a different version of the file.

Re-download or recover the original and test again before assuming something malicious happened. If it still fails against a reference you trust, don't use the file.

How to verify with Certelo?

If a file was anchored with Certelo, verification follows the same logic as any hash check. You supply the original file, or the hash or certificate information, and the record on the blockchain is checked for a matching fingerprint and its recorded time. If even a single byte of the file has changed since it was anchored, the new hash won't match the anchored one. Keep the exact original file, since a re-saved or converted copy will hash differently.

Frequently asked questions

What does it mean to verify a hash?

It means computing the hash of a file yourself and comparing it with a trusted reference value. An exact match confirms the file is identical to the one the reference came from.

Can two different files have the same SHA-256 hash?

In theory yes, since there are more possible files than possible hashes. In practice no collision has been found, and finding one is considered computationally infeasible with current knowledge. MD5 and SHA-1 are different: practical collisions exist, so they shouldn't be used for security.

Is a hash the same as encryption?

No. Encryption is reversible with a key. A hash is a one-way fingerprint that can't be turned back into the file.

Does a matching hash prove who created the file?

No. It shows the file is unchanged relative to the reference. It says nothing about who made it or who owns it.

Can someone fake a hash match?

Not by altering the file alone. But they can alter both the file and the published reference if you got both from the same compromised place. That's why the reference should come through a separate, trusted channel.

Does Certelo upload my file to create a record?

No. The SHA-256 hash is calculated locally on your device, and the original file doesn't need to be uploaded merely to create the proof.

What happens if I edit the file after anchoring it?

The edited file will produce a different hash, so it won't match the anchored record. The record still applies to the original version, which is exactly why you should keep that version untouched.

Is a hash enough to prove a file existed on a certain date?

No. A hash alone carries no date. You need an independent time reference, such as a trusted timestamping service or a blockchain record, tied to that hash.

Last Word

Hash verification is a simple, reliable way to tell whether a file has changed, as long as your reference value comes from somewhere you can trust. On its own it confirms integrity, not authorship or date. Pair it with an independent timestamp and you get a verifiable record that a specific file existed by a specific time, which is a more modest claim than "proof of ownership" and a more defensible one.