◇ OpenCyber Academy
Technical · Chapter 8 · English

Chapter 8 — Cryptography and trust services: failure modes

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 8 — Cryptography and trust services: failure modes

Lesson map

Lesson 08 published. Map, example, EX029.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Four classes of failure"]
  N2["8.2 Nonces and randomness"]
  N3["8.3 First responses"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX029"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Four classes of failure"]
  N2["8.2 Nonces and randomness"]
  N3["8.3 First responses"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX029"]
[Learning outcomes]
    |
    v
[8.1 Four classes of failure]
    |
    v
[8.2 Nonces and randomness]
    |
    v
[8.3 First responses]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX029]

Learning outcomes

You will (1) classify cryptographic failures as expiry, mismatch, misconfiguration or compromise; (2) explain nonce reuse and weak randomness in plain terms; (3) choose a first response for each class.

8.1 Four classes of failure

Priya groups past Lumen incidents into four classes. Expiry: a certificate or key passed its end date, so clients refused it. Mismatch: the certificate did not cover the host name, or the chain was incomplete. Misconfiguration: a server allowed obsolete protocol versions or a script disabled verification. Compromise: a private key or shared secret leaked. Tomás notices that the first three are operational and usually loud, because users see errors, while compromise is often silent. That difference shapes monitoring: loud failures need fast repair, silent ones need detection controls such as transparency monitoring and key-access logs.

8.2 Nonces and randomness

Some failures come from misuse inside software rather than settings. AES-GCM, described in NIST SP 800-38D, requires that a nonce never repeats under the same key; a repeat can reveal the relationship between two messages and lets an attacker forge authentication tags. Keys and nonces must come from a cryptographically secure generator, such as the operating system source wrapped by Python's secrets module, not from random, which is predictable. Tomás will not write such code for production, but he must recognise these mistakes in vendor advisories and code reviews, and know they need a vendor fix, not a configuration tweak.

8.3 First responses

For expiry, renew and deploy the certificate, then add monitoring. For mismatch, reissue with the correct names or fix the chain served by the host. For misconfiguration, change the setting through change control and retest. For compromise, revoke the certificate or rotate the secret immediately, find where the key was exposed, and review logs for misuse. Tomás writes these as a laminated card for the night shift. He adds that a technician who is unsure whether a case is misconfiguration or compromise should treat it as compromise until a senior engineer decides.

Worked example

Tomás sorts six synthetic incidents into the four classes and writes the matching first response for each on a one-page card.

Synthetic case. Incidents are invented; SP 800-38D is real.

Errors and limits

Classes overlap; an expired certificate replaced in a hurry with a self-signed one becomes misconfiguration. Silent compromise may never be detected.

Exercises

Synthesis

Classifying a failure as expiry, mismatch, misconfiguration or compromise tells the technician how urgent it is and what to do first.

Continue studying — chapter 08 of 18

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