A Hash Is a Fingerprint, Not a Verdict

Suppose two files have the same name:

status-policy.yaml
status-policy.yaml

Are they the same file content?

The filename cannot answer that.

Suppose they are both 842 bytes.

Still not enough.

Suppose they were modified at the same time.

Still not proof.

A cryptographic hash gives us a much stronger way to compare the bytes themselves.

The basic idea

A hash function accepts input data and produces a fixed-size output called a digest.

For SHA-256, the digest is 256 bits, commonly displayed as 64 hexadecimal characters.

Conceptually:

INPUT BYTES
    ↓
SHA-256
    ↓
FIXED-SIZE DIGEST

A harmless example might look like:

status-policy.yaml
        ↓ SHA-256
8f2a...<64 hexadecimal characters>...91c4

You do not need to calculate SHA-256 by hand. You do need to understand what the comparison means.

Same bytes, same digest

If you hash the exact same byte sequence with SHA-256, you get the same digest.

That makes hashes useful for questions such as:

• Did this downloaded file arrive with the same bytes as the publisher's reference?
• Did this configuration file change since I recorded a baseline?
• Are these two copies byte-for-byte identical?
• Did an evidence artifact change after capture?

The hash is a compact comparison value for the file content.

Tiny change, different digest

Now imagine a configuration contains:

admin_access: instructor

and someone changes it to:

admin_access: student

Only part of one line changed.

The SHA-256 digest should change dramatically because the input bytes changed.

This property helps expose modifications that might be easy to miss visually.

What a mismatch proves

Assume you created a trusted baseline digest at 09:00:

baseline SHA-256: AAAAA...1111

At 11:00 you hash the current file:

current SHA-256:  BBBBB...2222

The digests differ.

A defensible claim is:

The current file is not byte-for-byte identical to the file represented by the trusted baseline digest.

That is strong evidence of a content difference.

Now look at claims the mismatch does not prove:

• the file is malicious;
• an attacker changed it;
• the baseline was correct;
• the change caused an outage;
• the current file is unsafe;
• the original file was safe.

A hash comparison is an integrity observation, not a complete explanation.

What a match proves

Suppose the digest matches the trusted reference.

A defensible claim is:

The observed bytes match the artifact represented by the trusted SHA-256 reference.

That still does not prove the file is good.

If the trusted reference itself came from a bad source, a perfect match simply proves you have the same bad bytes.

This is why the reference source belongs in your evidence record.

Trust must come from somewhere else

Consider three reference digests.

Reference A

You generated the hash from your known-good classroom configuration immediately after your instructor provisioned the lab.

Useful baseline? Yes, assuming that provisioning state is the state you intend to preserve.

Reference B

A software publisher posts a checksum on its official release page and you independently obtain the file from the publisher's release channel.

Potentially useful? Yes. You still need to consider how you established that the page/source is authentic.

Reference C

A random forum post says:

“This is the correct hash, trust me.”

Useful as a trusted baseline? No reason yet.

The algorithm can be mathematically strong while the evidence chain is weak.

Hashes do not identify intent

Suppose status-policy.yaml changes overnight.

Possible explanations include:

• an approved update;
• a deployment process;
• a student lab activity;
• an administrator correction;
• accidental editing;
• automated formatting;
• corruption;
• unauthorized modification.

The mismatched digest does not select one explanation for you.

You need additional evidence.

That may include:

• change records;
• file metadata;
• deployment logs;
• service logs;
• version-control history;
• package-manager records; or
• a controlled reproduction.

This is the same evidence discipline from Weeks 1 and 2.

A hash is not encryption

Hashing and encryption solve different problems.

Encryption

Encryption is designed so authorized parties can recover the original plaintext using the necessary key/material.

PLAINTEXT → ENCRYPTION → CIPHERTEXT
CIPHERTEXT + KEY → DECRYPTION → PLAINTEXT

Hashing

A cryptographic hash is designed as a one-way digest operation for input data.

INPUT → HASH → DIGEST

You do not “decrypt a SHA-256 hash” to recover an arbitrary original file.

That phrase mixes two different mechanisms.

A hash is not a password strategy by itself

You may hear that passwords should be “hashed.” That is directionally true but incomplete.

Password storage has special requirements because human passwords are often low-entropy and guessable. Modern password storage normally uses purpose-built password hashing/key-derivation approaches with salts and intentionally expensive computation rather than a single fast raw SHA-256 pass.

That topic is separate from this week's file integrity use case.

Do not turn a file-integrity lesson into instructions for attacking password hashes.

Optional local observation

If your instructor gives you a harmless file in an approved local Linux environment, you can calculate SHA-256 with:

sha256sum approved-lab-file.txt

This command reads the local file and prints its digest.

It does not contact another system.

No-shell alternative

Use the supplied digest examples in this lesson. The required learning target is interpretation, not access to Linux.

Activity: what can you claim?

For each case, write the strongest defensible claim.

Case 1

Your current file's SHA-256 matches the baseline digest you recorded from the approved classroom image yesterday.

Case 2

Your current file's SHA-256 differs from yesterday's baseline.

Case 3

A downloaded file matches a checksum copied from an unverified chat message.

Case 4

Two differently named files produce the same SHA-256 digest and you trust the hashing implementation.

Case 5

A configuration file hash changed at the same time a service began failing.

For Case 5, resist the temptation to say the file change caused the failure. You have correlation and a useful hypothesis. Lesson 2 will test it.

Begin your Integrity Record

Record:

Artifact:
Purpose:
Reference source:
Why the reference is trusted:
Baseline digest:
Current digest:
Match / mismatch:
Strongest claim supported:
What the hash cannot prove:

If your record does not identify where the trusted digest came from, it is incomplete.

Before you leave

Remember this sentence:

A SHA-256 comparison can give strong evidence that bytes match or differ; it does not, by itself, explain cause, safety, authorship, or intent.

That is the boundary Lesson 2 depends on.