Hashing versus encryption: why they solve different problems

Two tasks for one imaginary message

A club treasurer sends a note: “Room booking: 120 units.” Consider two goals. First, the recipient wants to check that the note matches a previously agreed copy. Second, the treasurer wants outsiders to be unable to read it.

These goals call for different tools. Hashing produces a digest that can be recomputed for comparison. Encryption transforms plaintext into ciphertext using a key, with an intended decryption process that recovers the plaintext using the appropriate key.

A hash has no “decrypt” button because recovery is not its purpose. If you only keep the digest of the booking note, you have not made a recoverable encrypted archive. You have discarded the note and retained a comparison value.

Encryption, meanwhile, does not make a short universal fingerprint of a document. In a secure encryption scheme the result may include a nonce and authentication tag, and repeated encryption of the same message can produce different ciphertext. That variation can be desirable.

Ask what the reader needs later

If the club needs to read the note next month, it needs recoverable storage and appropriate key management. If it needs to check that an independently obtained copy matches a trusted original, a digest can help. If it needs to establish who authorized the note, the question has moved toward signatures or another authentication mechanism.

None of these operations fixes the note’s truth. A perfectly protected note can still contain an incorrect amount.

Work through the threat, not just the word

Goal	Candidate tool	What else matters?
Compare a file to a known reference	Cryptographic hash	The reference must itself be trustworthy
Store a recoverable private note	Authenticated encryption	Key storage, nonce rules, access and recovery
Check authorization of a message	Digital signature or MAC, depending on the setting	Correct key association and exact signed bytes
Verify a password without storing it directly	A purpose-built password hashing scheme	Salt, work factor and current implementation guidance

The final row is easy to get wrong. The SHA-256 playground shows a fast general-purpose hash. That is not a password-storage recipe. A human password often comes from a small searchable set; a fast hash lets an attacker test guesses quickly. Production password storage requires a separate threat model and a suitable maintained implementation.

Likewise, citing AES names a block cipher, not a complete messaging system. A developer still needs an appropriate mode and authentication, plus correct key and nonce handling. Building such a scheme from the primitives in this lesson would go beyond what the example establishes.

Classify four requests

Write compare, recover privately, or authenticate next to each request:

1. “Tell me whether my downloaded file matches this trusted release digest.”
2. “Let me open my private note tomorrow.”
3. “Tell me whether this public key verifies a signature over this exact message.”
4. “Hide my four-digit door code by publishing its SHA-256 hash.”

Expected answers: compare; recover privately; authenticate; and an unsuitable design. For the fourth request, an observer can hash every candidate code. Calling the digest irreversible does not remove this guessing attack.

Now explain why the first request mentions a trusted digest. If the source of both the file and its digest is compromised, matching the two does not establish that either is the intended release.