Chapter 8 — Programming II

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 High-level APIs"]
  N2["8.2 Structuring for safety"]
  N3["8.3 Negative tests"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 High-level APIs"]
  N2["8.2 Structuring for safety"]
  N3["8.3 Negative tests"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 High-level APIs]
    |
    v
[8.2 Structuring for safety]
    |
    v
[8.3 Negative tests]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) use high-level cryptographic APIs safely; (2) structure code to avoid misuse; (3) write negative tests.

8.1 High-level APIs

Priya learns that cryptographic libraries offer low-level primitives and high-level recipes. Low-level APIs require choosing modes, nonces and padding, where mistakes are easy. High-level APIs, such as an authenticated-encryption function that generates nonces and returns a single token, make safe use the default. For Tidewell's export tool, she uses a maintained library's authenticated-encryption recipe rather than assembling AES and a mode herself. The course rule is explicit: students learn how primitives work, but production code uses vetted high-level APIs. Teammates agree to follow it.

8.2 Structuring for safety

Priya isolates cryptography in one module with a small interface: protect(data) and unprotect(token). Keys are loaded from the consortium's secret store, never from source code. Errors in unprotect raise a single generic exception, so callers cannot learn why a token failed. She writes type hints marking secret values and avoids logging them. Code review focuses on this module, which is small enough to read carefully. The structure means future changes of algorithm affect one file rather than the whole application.

8.3 Negative tests

Priya writes tests that should fail: tampered tokens, truncated tokens, tokens protected with a different key and empty input. Each must be rejected. She also tests that two protections of the same data produce different tokens, confirming that nonces are fresh. A teammate's earlier version passed all positive tests while returning data even for tampered tokens, because it skipped tag verification. Negative tests caught it. She adds them to continuous integration so they run on every change. Each test has a one-line comment explaining its purpose.

Worked example

Priya uses a high-level authenticated-encryption recipe in a small protect/unprotect module, loads keys from a secret store and catches a skipped tag check with negative tests.

Synthetic case. The export tool is invented.

Errors and limits

High-level APIs still need correct key management. Tests prove only what they check.

Exercises

• EX022 — High-level advantage. Why prefer high-level cryptographic APIs?
  Show marking criteria

  Rubric: 3 = safe defaults handle nonces, modes and padding, reducing misuse;; 2 = safer;; 1 = faster;; 0 = none.
• EX023 — Generic exception. Why does unprotect raise one generic exception?
  Show marking criteria

  Rubric: 3 = so callers or attackers cannot learn why a token failed;; 2 = hide reason;; 1 = simpler;; 0 = none.
• EX024 — Fresh-nonce test. What does protecting the same data twice test?
  Show marking criteria

  Rubric: 3 = tokens differ, confirming fresh nonces;; 2 = nonces;; 1 = vague;; 0 = none.

Synthesis

Safe cryptographic code relies on high-level APIs, a small isolated module and negative tests that prove rejection.

Continue studying — chapter 08 of 40

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →