Chapter 5 — Security literacy

Chapter 5 — Security literacy

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Goals in council terms"]
  N2["5.2 Matching tools"]
  N3["5.3 Correcting misunderstandings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Goals in council terms"]
  N2["5.2 Matching tools"]
  N3["5.3 Correcting misunderstandings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Goals in council terms]
    |
    v
[5.2 Matching tools]
    |
    v
[5.3 Correcting misunderstandings]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) explain core cryptographic goals in council terms; (2) match tools to goals; (3) correct common staff misunderstandings.

5.1 Goals in council terms

Rosa explains cryptographic goals using council examples. Confidentiality keeps citizens' addresses and payment references private. Integrity ensures a signed council decision has not been altered after approval. Authentication confirms that a payment notification really came from the payment provider. Availability, though not provided by cryptography, can be harmed by it when certificates expire or keys are lost. Framing goals around real services helps non-technical colleagues see why each control exists, and helps Rosa decide which tool fits each need rather than reaching for encryption by habit.

5.2 Matching tools

Rosa builds a simple table. Encryption, such as AES-GCM from SP 800-38D, provides confidentiality and, being authenticated, integrity for stored or transmitted data. Hashing with SHA-256 from FIPS 180-4 provides fingerprints for integrity checks when the expected hash is trusted. HMAC from RFC 2104 authenticates messages between parties sharing a secret, such as payment webhooks. Digital signatures, such as Ed25519 from RFC 8032, let anyone verify signed council decisions with a public key. She adds a column for who holds keys in each case, connecting tools to operations.

5.3 Correcting misunderstandings

Rosa collects misunderstandings from colleagues: "We encrypt passwords so we can email them back if people forget"; "the PDF is signed, so it's confidential"; and "our VPN means internal websites don't need TLS". She corrects each gently: passwords should be hashed, not reversibly encrypted, so nobody can recover them; signatures prove origin and integrity but do not hide content; and internal traffic still benefits from TLS because insiders and compromised devices exist. She turns the list into a short quiz for new staff.

Worked example

Rosa maps four goals to council services, builds a tool table with key holders and corrects three staff misunderstandings in a quiz.

Synthetic case. Colleague quotes are invented.

Errors and limits

Tables oversimplify; authenticated encryption, for example, provides more than one goal. Availability depends on operations, not on algorithms.

Exercises

• EX013 — Integrity example. Which council example illustrates integrity? Rubric: 3 = a signed council decision not altered after approval;; 2 = example;; 1 = confidentiality example;; 0 = none.
• EX014 — Webhook tool. Which tool suits payment webhooks, and why? Rubric: 3 = HMAC, as both parties share a secret and need message authentication;; 2 = HMAC;; 1 = encryption;; 0 = none.
• EX015 — Password misconception. Correct "we encrypt passwords so we can email them back". Rubric: 3 = passwords should be hashed so nobody can recover them; use reset instead;; 2 = hash;; 1 = agree;; 0 = none.

Synthesis

Security literacy means matching each cryptographic tool to a concrete goal and correcting misconceptions in plain language.

Continue studying — chapter 05 of 30

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