Chapter 3 — Programming I

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Bytes and encodings"]
  N2["3.2 Hashing with hashlib"]
  N3["3.3 A file-integrity tool"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX007"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Bytes and encodings"]
  N2["3.2 Hashing with hashlib"]
  N3["3.3 A file-integrity tool"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Bytes and encodings]
    |
    v
[3.2 Hashing with hashlib]
    |
    v
[3.3 A file-integrity tool]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) handle bytes, encodings and hexadecimal in Python; (2) compute SHA-256 digests with hashlib; (3) check results against published test vectors.

3.1 Bytes and encodings

Priya's first programs show that computers store text as bytes according to an encoding. The string "café" becomes five bytes in UTF-8 because é needs two. Cryptographic functions take bytes, so she always writes text.encode("utf-8") before hashing. Hexadecimal displays bytes readably, two characters per byte. She practises converting with bytes.hex() and bytes.fromhex(). Small mistakes here, such as hashing a string with a trailing newline read from a file, produce entirely different digests, which taught her to print lengths and hex forms when debugging.

3.2 Hashing with hashlib

Python's hashlib implements SHA-256 from FIPS 180-4. Priya computes the digest of the empty string and of "abc" and compares them with the examples published with the standard: the "abc" digest begins ba7816bf. Matching a published vector proves she is calling the function correctly. She observes the avalanche effect: changing "abc" to "abd" changes about half of the 256 output bits. She learns that hashes are public functions, so anyone can compute them; a hash proves integrity only when the expected digest comes from a trusted source.

3.3 A file-integrity tool

Priya writes a small program that computes the SHA-256 digest of every file in a folder and saves a list, then later recomputes and reports changes. She uses Tidewell's synthetic catalogue export files for testing. Large files are read in chunks and fed to the hash object's update method, so memory use stays small. She documents a limit: an attacker who can modify both files and the saved list can hide changes, so the list must be stored somewhere protected or signed. This anticipates digital signatures later in the course.

Worked example

Priya confirms her SHA-256 calls against the FIPS 180-4 "abc" example, builds a chunked file-integrity checker, and records that the digest list itself needs protection.

Synthetic case. The catalogue files are invented; FIPS 180-4 is real.

Errors and limits

Hashes do not hide data and do not authenticate by themselves. Encoding mistakes are the most common cause of mismatched digests.

Exercises

• EX007 — UTF-8 length. Why is "café" five bytes in UTF-8?
  Show marking criteria

  Rubric: 3 = é takes two bytes;; 2 = encoding;; 1 = four;; 0 = none.
• EX008 — Test vector check. How did Priya confirm she used SHA-256 correctly?
  Show marking criteria

  Rubric: 3 = matched the FIPS 180-4 "abc" example digest beginning ba7816bf;; 2 = matched vector;; 1 = guessed;; 0 = none.
• EX009 — Integrity tool limit. What limit does the integrity checker have?
  Show marking criteria

  Rubric: 3 = attacker modifying files and the digest list hides changes; list must be protected or signed;; 2 = protect list;; 1 = vague;; 0 = none.

Synthesis

Careful byte handling, verified hashing and awareness of what a digest proves are the programmer's first cryptographic skills.

Continue studying — chapter 03 of 40

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →