Encoding, hashing, and encryption

A note can be converted into text characters, summarized by a digest, or protected with a secret key. Those operations have different jobs. Encoding changes representation using a public rule; standard Base64 is an example. Decoding reverses that public rule, so encoding does not keep a note secret.

A cryptographic hash produces a digest of a defined length for the chosen algorithm. It is designed to make reversing the digest or finding collisions impractical; it is not a reversible container for the original. Encryption turns readable plaintext into ciphertext using a key. Decryption recovers the plaintext with the appropriate key. Effective confidentiality also depends on a suitable algorithm and protecting the key.

Before you begin

Recommended first: How a web app is put together, Same-origin policy, Binary, hex, Base64, and URL encoding, Threat, vulnerability, and risk
Estimated time: 14 min reading, 10 min activity. Setup and optional practice may take longer.
Where you work: Read the fictional cards in any current desktop or mobile browser. No installation, account, password tool, directory deployment or network request is required. Use only the evidence supplied on this page.
Without a lab: The page prints the evidence needed for the activity. Write your classifications and reasons in notes, then compare them with the activity rubric. This practices reasoning; it does not reproduce a live incident or tool operation. Reading works without JavaScript. Answer checking requires JavaScript and a secure browser context; saving progress also requires usable browser storage.

After this lesson you can:

Classify a declared operation as encoding, hashing, or encryption.
Say which of the three is built to keep a note secret with a key.
Explain why a digest proves a match only when the reference digest is trusted.

01Example

These fictional bags state their operation and key handling. Read the purpose of each operation; the displayed labels are not computed results.

Postcard: standard Base64, no key. Public representation. Not secrecy.
Tag: a hash function, no key. Fixed-length digest. Not secrecy.
Envelope: encryption. The key is held by the recipient and is not printed.
The envelope is the operation that keeps the note secret from someone without the key.

02Job, then key

Use the declared operation and its purpose, rather than guessing from appearance. Hexadecimal characters alone do not establish whether something is a digest, a key or ordinary data. The fixed-length rule describes a chosen hash function, not every possible transform.

A digest can support an integrity comparison when the expected digest comes through a trusted route. If someone can replace both a file and the digest beside it, they can supply a matching pair. Encryption serves confidentiality, while authenticated encryption also detects unauthorized changes. The published one-byte XOR toy from Code is not suitable protection for a real note.

Choose encoding, hashing, or encryption from the job and from whether a key is required.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

publicsecret

Field	Postcard	Tag	Envelope
Declared job	Standard Base64	Hash function	Encryption
Key role	No key	No key	Held by recipient; not printed
Result role	Public representation; not secrecy	Fixed-length digest; not secrecy	Keeps note secret from someone without the key

Neither supplies secrecy

Base64 changes representation and a hash gives a digest; no secret is computed here.

Follow the explanation

Base64 changes representation and a hash gives a digest; no secret is computed here.
The declared encryption role preserves secrecy from someone lacking its key; the key and ciphertext are not printed.

Read every state and value

1. Base64 changes representation and a hash gives a digest; no secret is computed here.

Selected Comparison: public
Highlighted Field: Declared job · Key role

2. The declared encryption role preserves secrecy from someone lacking its key; the key and ciphertext are not printed.

Selected Comparison: secret
Highlighted Field: Key role · Result role

Purpose and key handling distinguish operations; appearance alone does not.

03Sort three bags

Bags E, H, and C name their operations. The check is the bag whose job is representation.

Original fictional bags. No program encoded, hashed, or encrypted a value for this card.

Worked bags
Bag postcard
Declared operation: standard Base64
Key: none
Job: write bytes in the public alphabet from the encodings lesson
Secrecy: no. Anyone who knows that public alphabet can reverse it.

Bag tag
Declared operation: a hash function with a fixed-length result
Key: none
Job: produce a digest of the bytes
Secrecy: no. A digest is not ciphertext.
Comparison limit: a digest supports a comparison when the reference digest comes from a source you trust. A digest from the same person who can change the file matches the changed file.

Bag envelope
Declared operation: encryption
Key: held by the recipient and not printed on this card
Job: change the note into ciphertext so someone without the key does not learn the note
This is not the one-byte XOR toy. That toy used a published key.

Activity bags
Bag E
Declared operation: standard Base64
Goal written on the bag: send the bytes through a text form
Key: none

Bag H
Declared operation: a hash function
Goal written on the bag: compare this digest with a digest from a trusted source
Key: none

Bag C
Declared operation: encryption
Goal written on the bag: keep the note secret
Key: held by the recipient and not printed

Check: bag E is encoding.

Download the operation cards

Copy each bag's declared operation, its goal, and whether a key is printed.
Match encoding, hashing, and encryption to the three bags.
Check: bag E is encoding. Bag H prints no key. Bag C is the remaining bag, and its key is not printed.
Stop. Do not run a transform. The bags are labels, not program output.

04Optional challenge

Allow about ten minutes. Explain why a replaced file and a newly supplied matching digest do not establish that the file is the original. Your note should identify the missing trusted reference and one separate route through which an expected digest could be obtained.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Operation case A: independent declared jobsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

R: convert a note’s bytes to standard Base64 for a text form; no key.
S: apply a named fixed-length hash function and compare its digest to a trusted expected digest.
T: protect a private note as ciphertext; the recipient holds the secret key and it is not published.
These are declared operations, not computed output.

Operation case B: changed reference sourceOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

A learner downloads a file and its expected digest from one editable public post. An adversary can replace both. The replacement file’s newly supplied digest matches. No separately trusted reference is supplied.

06Explain your prediction

Optional written self-check: Name the operation, key handling, intended job and remaining trust assumption. Do not turn decoding into decryption or a matching untrusted digest into an authenticity claim.

07Common mistakes

If you called bag E encryption, you treated a public alphabet as a key. Base64 reverses without a secret.

If you called bag H encryption, you treated a digest as ciphertext. The bag prints no key and no decryption step.

If you trusted a digest that arrived with the file from the person who can edit it, you skipped the trusted-reference rule.

Check 1
Use case A. Match each declared job to its operation.
- R: Base64 text form
- S: trusted digest comparison
- T: recipient-key protection
Check 2
A new task is to send a private note so someone without the recipient’s key cannot read it. Which operation from case A fits that goal?
Select one line.
- Use the declared keyed encryption design with its appropriate key handling.
- Use Base64 because unfamiliar letters make public reversal impossible.
- Send only a digest and expect the recipient to decrypt it into the complete original note.
Check 3
Use independent case B. What does the matching digest establish about the original file?
Select one line.
- It does not establish originality because the file and reference could both be replaced; a trusted reference is missing.
- A matching digest proves the file is the original regardless of who supplied the reference.
- Any unkeyed digest identifies the author and grants permission to run the file.

0 of 3 required checks answered.

Practice

Practice with the supplied security casesRepeat the activity in your notes and explain each decision from the printed facts. No external target or account is needed.

References

NIST CSRC glossary: hash function
An approved hash function has a fixed-length output and is designed to be one-way and collision-resistant. The page names FIPS 180 and FIPS 202. No digest was computed.
NIST CSRC glossary: encryption
One definition is changing plaintext into ciphertext using a cryptographic algorithm and a key. The page attributes that sentence to SP 800-133 Rev. 2.
OWASP Password Storage Cheat Sheet
The hashing-versus-encryption section. Hashing is treated as one-way. Encryption can be reversed by someone with the key. The page says passwords should be hashed rather than encrypted. No edition number was printed.
RFC 4648: Base64
This lesson does not quote that RFC.