Hashes, MACs, and signatures

A fictional museum publishes a new opening-hours notice. A visitor wants to know whether the file changed, whether it came from the museum, and whether the hours are correct. Those sound like one question, but different evidence answers each part. Hashes, message authentication codes, and digital signatures are useful because their guarantees are specific.

A digest helps compare content

A cryptographic hash maps a message to a fixed-length digest for that algorithm. The same exact input gives the same digest. A suitable modern hash makes it computationally difficult to find particular kinds of matching inputs, but its finite output does not mean collisions are mathematically impossible.

If you compare a downloaded notice with an independently trusted digest, a match provides evidence that the content agrees with that reference, under the algorithm’s security assumptions. A different digest indicates different input. The comparison does not explain which version is correct.

An unknown website supplying both the file and its digest has supplied two mutually consistent objects, not independent evidence of museum authorship. Hashing also does not encrypt the notice. Someone can guess a short input, hash that guess, and compare it; the term “one-way” does not turn predictable information into a secret.

A MAC adds a shared secret

A message authentication code, or MAC, uses a secret key to generate and verify a tag over a message. HMAC is a standardized construction based on a cryptographic hash. With a suitable key, algorithm, and implementation, the check can detect unauthorized alteration and support authentication among parties sharing that key.

Suppose the museum’s scheduling and display teams share one MAC key. Each can verify a tagged notice, but each can also create a valid tag. A third party cannot infer which team authored a message merely because the shared-key check succeeds. That is a meaningful limit, not a defect in the mechanism.

A signature separates creating from checking

A digital signature uses a signing private key and a corresponding verification public key. The museum can keep its signing key private while distributing a public key for visitors to verify notices. The verifier still needs a trustworthy association between that public key and the museum. Accepting a replacement key from the same untrusted message does not establish that association.

A valid signature supports integrity and source authentication under those assumptions. It does not hide the notice, prove the signer made no mistake, or establish that an old notice is still current. Protecting signing keys, checking applicable validity information, and managing changes remain part of the design.

PredictA visitor verifies a genuine museum signature on last winter’s timetable. Does it prove the museum closes at that time today?

No. The signature can authenticate that particular timetable. The visitor also needs its effective dates and any replacement notice. Authenticity and current applicability are different claims.

Ask what the check actually proves

For each design, name the content, the trusted reference or key, and the intended claim. If confidentiality is needed, add suitable encryption. If replay or outdated information matters, the surrounding protocol needs freshness rules. If the announcement itself might be mistaken, factual review remains necessary. Cryptographic evidence becomes useful when its scope is understood.