Chapter 30 — Laboratory II

Chapter 30 — Laboratory II

Lesson map

Lesson 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 Improving the export tool"]
  N2["30.2 Testing the new design"]
  N3["30.3 Evaluating the design"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 Improving the export tool"]
  N2["30.2 Testing the new design"]
  N3["30.3 Evaluating the design"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 Improving the export tool]
    |
    v
[30.2 Testing the new design]
    |
    v
[30.3 Evaluating the design]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) replace manual key sharing with a public-key exchange in a lab; (2) sign and verify exported files; (3) evaluate the improved design.

30.1 Improving the export tool

Laboratory II returns to the export tool from Laboratory I, whose weak point was manual key sharing. Priya's team redesigns it with hybrid public-key encryption: the partner library publishes a public key, and the tool encrypts each export with a fresh symmetric key wrapped for that public key, following the hybrid public key encryption pattern in RFC 9180, using a vetted library. The team also signs each export with Tidewell's Ed25519 key so the partner can verify its origin. Each export carries its signature beside it.

30.2 Testing the new design

Tests check that the partner can decrypt and verify; that a file signed with the wrong key fails verification; that a file encrypted for another partner cannot be decrypted; and that tampering is detected. A test reveals that the tool signed the plaintext but the partner verified after decryption with a different associated data value, causing false failures. The team aligns the signed content definition in both tools, learning that sender and receiver must agree exactly on what is signed.

30.3 Evaluating the design

Priya evaluates improvements: no shared secret moves by email; each export has its own key; origin is verifiable. Remaining issues include distributing and trusting the partner's public key, which the team handles by exchanging key fingerprints in a meeting, and key rotation for both parties. She records that the team used library functions throughout and implemented no cryptographic primitives. The evaluation compares the designs in a table with security, usability and operational effort. Grace agrees to adopt the design for real partner exports.

Worked example

The team replaces manual key sharing with library-based hybrid public-key encryption and Ed25519 signatures, fixes a mismatch in signed content and evaluates the design.

Synthetic case. The lab is invented; RFC 9180 and RFC 8032 are real.

Errors and limits

Public keys must be authenticated, for example by fingerprint comparison. Mismatched definitions of signed content cause false failures or gaps.

Exercises

• EX088 — Hybrid pattern. How does the new tool encrypt exports? Rubric: 3 = fresh symmetric key per export wrapped for partner's public key (RFC 9180 pattern);; 2 = wrapped;; 1 = shared password;; 0 = none.
• EX089 — Signature mismatch. What caused false verification failures? Rubric: 3 = sender and receiver disagreed on signed content definition;; 2 = mismatch;; 1 = wrong key;; 0 = none.
• EX090 — Fingerprint exchange. How did the team trust the partner's public key? Rubric: 3 = exchanged key fingerprints in a meeting;; 2 = fingerprints;; 1 = trusted email;; 0 = none.

Synthesis

Public-key encryption and signatures remove shared-secret transfer, provided keys are authenticated and both sides agree on what is signed.

Continue studying — chapter 30 of 40

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →