Chapter 9 — Programming II

Chapter 9 — Programming II

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Wrapping libraries safely"]
  N2["9.2 Errors that do not leak"]
  N3["9.3 Testing cryptographic code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Wrapping libraries safely"]
  N2["9.2 Errors that do not leak"]
  N3["9.3 Testing cryptographic code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]

[Learning outcomes]
    |
    v
[9.1 Wrapping libraries safely]
    |
    v
[9.2 Errors that do not leak]
    |
    v
[9.3 Testing cryptographic code]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) structure code that calls cryptographic libraries safely; (2) handle errors without leaking information; (3) test cryptographic code with known-answer and negative tests.

9.1 Wrapping libraries safely

Aiyana writes a small module that the meter-reading service will call for authentication. It exposes two functions, tag a reading and verify a reading, and hides all key handling and algorithm choices inside. Callers cannot choose algorithms or pass raw keys. This wrapper pattern reduces misuse: developers cannot accidentally use a weak hash or compare tags with ordinary equality. Marcus reminds her that the wrapper delegates to the standard library's hmac and hashlib, which implement RFC 2104 and FIPS 180-4, rather than reimplementing any primitive.

9.2 Errors that do not leak

When verification fails, the service must not tell the caller why, for example whether the meter identifier was unknown or the tag was wrong, because detailed errors help attackers probe the system. Aiyana's verify function returns only true or false to the caller and writes the detailed reason to a protected log. She also ensures exceptions never include key material or full readings in their messages. These rules reflect a broader principle: in security code, convenience for debugging must not become information for attackers.

9.3 Testing cryptographic code

Aiyana writes three kinds of tests. Known-answer tests check her wrapper against published vectors, such as RFC 4231 values for HMAC-SHA256, confirming correct use. Negative tests check that an altered reading, a wrong key or a truncated tag all fail. Property tests generate many random readings and confirm that tag-then-verify always succeeds. She learns that negative tests are often missing in practice, so a verification function that always returns true could pass every positive test. Her test suite runs on every change in continuous integration.

Worked example

Aiyana's wrapper exposes only tag and verify, returns bare true or false, logs details privately, and passes known-answer, negative and property tests.

Synthetic case. The service and wrapper are invented; RFC 2104 and FIPS 180-4 are real.

Errors and limits

Wrappers can hide bugs as well as complexity; they must be reviewed and tested. A test suite without negative cases cannot catch a verifier that accepts everything.

Exercises

• EX025 — Wrapper benefit. How does the wrapper reduce misuse? Rubric: 3 = callers cannot choose algorithms, pass raw keys, or compare tags unsafely;; 2 = hides details;; 1 = faster;; 0 = none.
• EX026 — Silent failure. Why does verify return only true or false to callers? Rubric: 3 = detailed reasons help attackers probe; details go to protected logs;; 2 = security;; 1 = simpler;; 0 = none.
• EX027 — Missing negative tests. What danger do negative tests guard against? Rubric: 3 = a verifier that always returns true passing all positive tests;; 2 = bugs;; 1 = vague;; 0 = none.

Synthesis

Safe cryptographic programming wraps vetted libraries, reveals little on failure and proves behaviour with positive and negative tests.

Continue studying — chapter 09 of 50

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →