◇ OpenCyber Academy
Rapid course · Chapter 3 · English

Chapter 3 — Cryptography and trust services: systems, data and dependencies

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Cryptography and trust services: systems, data and dependencies

Lesson map

Lesson 03 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Systems and their cryptography"]
  N2["3.2 How passwords should be stored"]
  N3["Lab — Salted password storage"]
  N4["3.3 Depending on suppliers"]
  N5["3.4 Why things expire"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Systems and their cryptography"]
  N2["3.2 How passwords should be stored"]
  N3["Lab — Salted password storage"]
  N4["3.3 Depending on suppliers"]
  N5["3.4 Why things expire"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]

[Learning outcomes]
    |
    v
[3.1 Systems and their cryptography]
    |
    v
[3.2 How passwords should be stored]
    |
    v
[Lab — Salted password storage]
    |
    v
[3.3 Depending on suppliers]
    |
    v
[3.4 Why things expire]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes

You will (1) list the library's systems and where cryptography is used; (2) explain how passwords should be stored; (3) recognise dependencies on outside suppliers; (4) understand why keys and certificates expire.

3.1 Systems and their cryptography

With Inês, Leo lists the library's systems. The website uses TLS so visitors' connections are private. The e-book account system stores members' passwords and is run by an outside supplier. Staff laptops use built-in disk encryption, so a stolen laptop does not expose files. Public Wi-Fi uses a shared password, which keeps out casual neighbours but does not protect users from each other. The newsletter platform signs outgoing email so receivers can tell it really comes from the library. Leo is surprised how many places use cryptography quietly, without anyone at the library thinking about it.

3.2 How passwords should be stored

Leo asks how a website remembers his password. Inês explains that a good system never stores the password itself. It stores the result of a slow, salted password-hashing function such as scrypt, described in RFC 7914, or Argon2id, described in RFC 9106. The salt is a random value per user, so two members with the same password get different stored results. When you log in, the system repeats the calculation and compares. If thieves steal the database, slow hashing makes guessing expensive. The lab below shows salted storage on synthetic accounts using Python's standard library.

Lab — Salted password storage

# Salted scrypt storage for synthetic members. Teaching only; real systems use maintained libraries.
import hashlib, hmac, secrets
P = dict(n=2**14, r=8, p=1, dklen=32)
def store(pw):
    s = secrets.token_bytes(16); return s, hashlib.scrypt(pw, salt=s, **P)
def check(pw, rec): return hmac.compare_digest(hashlib.scrypt(pw, salt=rec[0], **P), rec[1])
m1, m2 = store(b"ReadMore2026"), store(b"ReadMore2026")
print("same password, same stored value?", m1[1] == m2[1])
print("member 1 right password:", check(b"ReadMore2026", m1))
print("member 2 right password:", check(b"ReadMore2026", m2))
print("member 1 wrong password:", check(b"ReadLess2026", m1))

Run with python3 lab_salted.py. Verified output:

same password, same stored value? False
member 1 right password: True
member 2 right password: True
member 1 wrong password: False

3.3 Depending on suppliers

Many of the library's protections are run by others. The e-book supplier stores members' password hashes; the newsletter platform holds the email signing key; the web host renews the website certificate. The library cannot change these settings directly, but it depends on them. Inês shows Leo how to check what the supplier promises, for example in its security page or contract, and who to contact if something goes wrong. Knowing the dependency list means that when a supplier announces a problem, the library knows at once whether members are affected and what to tell them.

3.4 Why things expire

Certificates and some keys have end dates. A certificate that expires makes browsers show warnings, which happened to the library website last year when the web host's automatic renewal failed silently. Expiry exists so that a key cannot be used forever if it was quietly stolen, and so that settings get refreshed. Inês now keeps a simple calendar of expiry dates with reminders a month ahead, even for items suppliers renew automatically. Leo learns that cryptography is not set-and-forget: someone must watch dates, renewals and suppliers, or the protection itself can cause an outage.

Worked example

Leo builds a five-row table of library systems, their cryptographic use and who controls them, runs the salted storage lab and adds the website certificate to the expiry calendar.

Synthetic case. Systems, suppliers and the past outage are synthetic; RFC 7914 and RFC 9106 are real.

Errors and limits

A shared Wi-Fi password gives limited protection between users. Supplier promises still need checking over time.

Exercises

Synthesis

Small organisations depend on cryptography in many systems and suppliers, so they must know where it is used and watch passwords, keys and expiry dates.

Continue studying — chapter 03 of 04

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