Week 1

Security Mindset & Threat-Modeling a Cryptographic System

Security & Cryptography · Nutthakorn Chalaemwongwan

Today

• The course's spine: textbook-secure primitive, real-system failure
• What "cryptographically secure" promises — and doesn't
• CIA triad, applied precisely to cryptography
• Trust boundaries + a lightweight threat-modeling process
• 🐍 Game: Snake Oil Bingo

The course's spine

Every remaining teaching week takes one mathematically sound primitive and shows one specific, real way it fails when misused:

Textbook-secure primitive, real-system failure.

• The primitive's proof holds
• The deployment breaks it anyway
• Implementation bugs, bad randomness, protocol misuse, side channels, key-management failure — never the math itself

Preview: the pattern, week by week

(Full 11-row table is in this week's README — you'll hypothesize about two unseen rows in the worksheet.)

What "cryptographically secure" actually promises

• A primitive resists a well-defined class of mathematical attack
• Under stated assumptions (e.g. discrete log is hard in this group)
• At a stated security level (e.g. 128-bit, 256-bit)

That's it. It says nothing about:

• Whether the program calling it is secure
• Whether keys are generated, stored, or rotated safely
• Whether the protocol around it is composed correctly

CIA, specifically for cryptography

"We encrypted it" is a confidentiality claim only

• Encryption alone answers: can an adversary read this?
• It does not answer: can an adversary tamper with it undetected?
• Encryption with no integrity mechanism → ciphertext can be modified in structured, exploitable ways

Encrypt-then-MAC, or a proper AEAD mode, is what actually closes this gap (Week 6). Week 4 shows exactly how the gap gets exploited.

Trust boundaries around key material

A trust boundary = any point where control over, or visibility into, key material changes hands:

• Client vs. server
• Application vs. OS keystore / HSM
• One microservice vs. another
• A developer's laptop vs. production

Every crossing is where key-management failures concentrate: hardcoded keys in source control, keys logged in plaintext, keys shared across environments, no rotation or revocation path.

Real incident: sound primitive, broken deployment

Debian OpenSSL predictable-RNG bug (CVE-2008-0166)

• OpenSSL's PRNG itself: mathematically fine
• A Debian packaging patch cut the entropy-gathering code
• Result: only ~32,768 possible keys per key type, system-wide
• CWE-330 — Use of Insufficiently Random Values

Real incident: the PS3's signing key

fail0verflow, "Console Hacking 2010" (27C3)

• Sony used ECDSA — mathematically sound — to sign PS3 firmware
• The implementation reused the same nonce for every signature
• Reused nonce + two signatures → private signing key algebraically recoverable
• Result: anyone could sign arbitrary "official" firmware

This week's break: an AI that's never technically wrong

• No primitive has been taught yet — nothing to exploit in code
• Instead: a real, professionally-worded AI answer to "why does textbook-secure crypto fail in real systems?"
• Every individual factual claim in it is true
• It still has exactly one systematic, load-bearing gap

Finding that gap is this week's exploit — a reasoning exploit instead of a code exploit.

The Exhibit's shape (don't solve it yet)

The AI's answer explains real-world crypto failure entirely in terms of:

• Insufficient key length (DES-56, RSA-1024)
• Outdated algorithm choices (SHA-1, MD5)
• "Stay current with NIST key-length guidance" as the fix

It's all correct. It is also only one of several failure categories — compare it against everything on this slide deck so far.

The correct construction: threat model before you code

Lightweight process, applied to a system that handles cryptographic keys:

1. Assets — what needs protecting (keys, plaintext, session tokens)
2. Adversaries — who's attacking, what can they see/touch
3. Attack surface — every trust boundary the assets cross
4. Ask, at each primitive: what assumption does this rely on, and does this system actually uphold it?

🐍 Signature game — Snake Oil Bingo

• Everyone gets a bingo card of common crypto myths: "military-grade encryption," "unbreakable 256-bit security," "quantum-proof because the key is long enough"
• As the Exhibit is read aloud and picked apart, mark a square the moment its myth surfaces
• A square only counts once your table gives the one-line technical reason it's wrong
• First verified BINGO wins

Lab today — Worksheet 1

📋 Worksheet 1 — labs/week01-intro/worksheet.md · Parts 1–5 · 180 min No Docker, no flag — conceptual week, rubric-graded

• Part 2 — 6 short-answer questions (CIA, trust boundaries, the throughline)
• Part 3 — Audit-the-AI (required): name the Exhibit's gap + 2 examples
• rewrite its summary paragraph
• Part 4 — Explain-in-Plain-English + a Prompt Problem
• Part 5 — Viva spot-check, live, no notes

Takeaway

• "Cryptographically secure" is a claim about math, not about your system
• Real failures cluster at the boundary: bad randomness, key management, protocol misuse, side channels — rarely the primitive itself
• Textbook-secure primitive, real-system failure — this is the lens for every remaining week

Questions?

Next week: Cryptographic hash functions