Disclaimer: This study guide attempts to touch upon the most important topics that may be covered on the exam but does not claim to necessarily cover everything that one needs to know for the exam. Finally, don't take the one hour time window in the title literally.

Last update: Mon Sep 29 18:22:05 2025

Foundations of Computer Security

Key terms

Computer security protects systems and data from unauthorized access, alteration, or destruction. The CIA Triad summarizes its core goals: confidentiality, integrity, and availability.

Confidentiality: Only authorized users can access information. Related terms:

• Privacy: control over personal information.

• Anonymity: hiding identity.

• Secrecy: concealing existence of information.

• Exfiltration: unauthorized transfer of data out of a system.

Integrity: Ensures accuracy and trustworthiness of data and systems. Integrity includes data integrity (no unauthorized changes), origin integrity (verifying source), recipient integrity (ensuring correct destination), and system integrity (software/hardware functioning as intended). Authenticity is tied to integrity: verifying origin along with correctness.

Availability: Ensures systems and data are usable when needed.
Threats include DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks, hardware failures, and failed backups.

System Goals
Security systems aim at prevention, detection, and recovery. Prevention stops attacks, detection identifies them, and recovery restores systems after incidents. Forensics investigates what happened. Defense in Depth is a layered strategy that applies multiple overlapping defenses — technical, procedural, and sometimes physical. If one control fails, others still provide protection.

Policies, Mechanisms, and Assurance

• Policies: Define what is allowed.

• Mechanisms: Enforce policies.

  • Technical mechanisms: include operating system controls and cryptography.

  • Procedural mechanisms: include audits, ID checks, and separation of duties.

• Assurance: Confidence that policies and mechanisms are correctly implemented.

• A principal is an entity that can be uniquely identified and authenticated.

• A subject is the active process acting on behalf of a principal.

• All security depends on assumptions about users, environments, and trusted components.

Security Engineering and Risk Analysis
Security engineering balances cost, usability, and protection.
Risk analysis evaluates asset value, likelihood of attack, and potential costs. Tradeoffs matter: too much protection may reduce usability or become too costly.

Trusted Components and Boundaries

• The Trusted Computing Base (TCB) is all the hardware, firmware, and software essential to enforcing security.

• A trust boundary is where data passes between trusted and untrusted entities.

• Supply chain security is critical: a trusted vendor can become an attack vector.

Human Factors People remain the weakest link. Weak passwords, poor training, and misaligned incentives undermine protection.

• Security theater: Measures that look protective but add little real security.

• Weakest link: Security is only as strong as the most vulnerable component.

Threats, Vulnerabilities, and Attacks

A vulnerability is a weakness in software, hardware, or configuration. Examples include buffer overflows, default passwords, and weak encryption. Hardware-level flaws include Spectre, Meltdown, and Rowhammer.

An exploit is a tool or technique that leverages a vulnerability. An attack is the execution of an exploit with malicious intent.

An attack vector is the pathway used to deliver an exploit, such as email, websites, USB drives, or open network ports. The attack surface is the total set of possible entry points.

Not all vulnerabilities are technical. Social engineering manipulates people into granting access or revealing information. Phishing, spear phishing, pretexting, and baiting are common techniques. (This will be explored in more detail later in the course.)

A threat is the possibility of an attack, and a threat actor is the adversary who may carry it out. One useful classification, described by Ross Anderson, distinguishes threats as disclosure (unauthorized access), deception (false data), disruption (interruptions), and usurpation (unauthorized control). Related concepts include snooping, modification, masquerading, repudiation, denial of receipt, and delay.

The threat matrix distinguishes between opportunistic vs. targeted attacks and unskilled vs. skilled attackers (from script kiddies to advanced persistent threats).

The Internet amplifies risk by enabling action at a distance, anonymity, asymmetric force, automation at scale, global reach, and lack of distinction between malicious and normal traffic.

A botnet is a network of compromised machines controlled via a command and control server, used for spam, phishing, cryptocurrency mining, credential stuffing, or DDoS attacks.

Adversaries and Cyber Warfare

Behind every attack is an adversary. Adversaries differ in their goals, risk tolerance, resources, and expertise.

Types include:

• Hackers:

  • White hats: defensive security researchers who find and report flaws.

  • Black hats: malicious attackers seeking profit or disruption.

  • Gray hats: operate in a legal or ethical gray zone, sometimes disclosing flaws responsibly and sometimes not.

• Criminal groups: organized gangs running fraud, ransomware, or “malware-as-a-service.”

• Malicious insiders: employees or contractors who abuse legitimate access.

• Hacktivists: politically or socially motivated attackers.

• Spies: industrial or state-backed espionage actors.

• Press or politicians: may try to obtain sensitive information to gain an advantage, but are usually risk-averse due to reputational or legal consequences.

• Police and law enforcement: have legal authority (e.g., warrants, evidence seizure), but can also overstep through illegal searches or surveillance.

• Nation-states: governments capable of long-term, well-funded operations.

Economic incentives sustain underground markets where exploits, botnets, and stolen data are sold. Zero-day vulnerabilities can fetch high prices in closed broker markets. By contrast, bug bounty programs reward researchers for legal disclosure.

Advanced Persistent Threats (APTs) are advanced in their methods, persistent in maintaining access, and threatening in their ability to bypass defenses. They are typically state-backed and operate over months or years with stealth and patience.

Cyber warfare involves state-sponsored attacks on critical infrastructure and military systems.

Countermeasures include government and industry cooperation, international botnet takedowns, and intelligence sharing.

The implication is that cybersecurity affects all levels: national security, corporate security, and personal security. Cyber warfare blurs the line between peace and conflict. Attribution is difficult, and critical infrastructure, businesses, and individuals alike are potential targets.

Tracking Vulnerabilities and Risks

Why track vulnerabilities?
Early vulnerability reporting was inconsistent. The CVE system (1999) introduced standardized identifiers. CVSS added a way to score severity. Together, they form the backbone of how vulnerabilities are shared and prioritized.

CVE (Common Vulnerabilities and Exposures)

A unique identifier assigned to publicly disclosed vulnerabilities. Example: CVE-2021-44228 (Log4Shell).

CVSS (Common Vulnerability Scoring System)

A 0–10 scale for rating the severity of vulnerabilities, based on exploitability and impact. Scores are grouped into categories from Low to Critical.

Attribution challenges

Attackers obscure their origins, reuse tools, share infrastructure, and sometimes plant false flags. This makes it difficult to know with certainty who is behind an attack.

APT (Advanced Persistent Threat)

Well-funded, skilled groups (often state-backed) that carry out prolonged, targeted campaigns. Advanced = may use custom malware, zero-days, or sophisticated tradecraft; Persistent = long-term stealthy presence; Threat = ability to bypass defenses.

Foundations of Symmetric Cryptography

Kerckhoffs’s Principle. A system must remain secure even if everything about it is public except the key. Prefer standardized, openly analyzed algorithms; avoid secrecy of design.

Schneier’s Law. Anyone can design a cipher they cannot break; confidence comes only after broad, sustained public scrutiny.

Why cryptography. Protect against passive adversaries (eavesdropping) and active adversaries (injection, modification, replay). Core goals: confidentiality, integrity, authenticity.
Note: Non-repudiation is a protocol-level property we will cover later with public-key tools.

Core terms. Plaintext (original data), ciphertext (encrypted data), cipher (algorithm), key (secret parameter selecting one transformation), encryption / decryption (apply the cipher with a key), symmetric encryption (same secret key shared by sender and receiver).

Design stance. Open algorithms + secret keys; explicit threat assumptions; careful key management (generation, sharing, storage). Modes, authentication, and detailed cryptanalysis come later.

Historical pointer. Classical systems supplied two ingredients—substitution and transposition—that motivate Shannon’s later principles (confusion and diffusion).

Main takeaway. Use vetted primitives; be precise about which goal you’re achieving and against which attacker; most real mistakes come from sloppy assumptions and imprecise terminology.

Classical Ciphers (Substitution and Transposition)

Classical ciphers. Hand methods that illustrate substitution (change symbols) and transposition (reorder symbols). Alone, each leaks patterns.

Caesar cipher. Shift letters by a fixed amount; trivial to brute force and defeat via frequency counts.

Monoalphabetic substitution. Any fixed mapping; keyspace is large (\(26!\)) but frequency analysis breaks it. In English, E, T, A, O, I, N are common; Z, Q, X, J are rare; frequent digraphs TH, HE, IN and trigrams THE, AND stand out.

Frequency analysis (idea). Count the frequencies of single letters, digraphs (pairs of letters), trigraphs (triples of letters); align peaks and legal word shapes; refine with language constraints (double letters, common endings).

Alberti’s cipher disk (1460s). Two concentric alphabets; rotate the inner disk to switch substitution alphabets periodically mid-message. Early polyalphabetic* encryption that blurs single-letter statistics.

Vigenère cipher (16th c.). Repeat a keyword over the plaintext; each key letter selects a Caesar shift alphabet (via a table lookup of plaintext row vs. key column). The same plaintext letter can encrypt differently depending on its alignment with the key.

Breaking Vigenère (Babbage–Kasiski). Find repeated ciphertext fragments; measure gaps; factor to guess key length; split text into that many streams and solve each stream as a Caesar cipher by frequency.

Transposition ciphers. Preserve letters, change order.
• Scytale: wrap a strip around a rod; write along the rod; read off unwrapped.
• Columnar transposition: write plaintext in rows under a keyword; read columns in keyword order. Padding (often X) fills incomplete rows and can leak hints.

Some later ciphers, like Playfair and ADFGVX combine substitution and transposition.

Lessons. Combining substitution and transposition helps, but hand systems leave structure to exploit. These methods motivated mechanized cryptography (rotor machines) and later, theory-driven designs that deliver confusion and diffusion deliberately.

Mechanized Cryptography (Rotor Machines)

Goal. Show how machines automated polyalphabetic substitution and why complexity alone did not guarantee security.

Rotor machine. A stack of wired wheels applies a changing substitution on each keystroke; the rightmost rotor steps like an odometer, so the mapping evolves continuously.

Enigma workflow. Type a letter, current rotor positions map it through three rotors, a reflector sends it back through the rotors on a different path, and a lamp shows the ciphertext. Same setup decrypts. The use of a reflector implies that no letter ever encrypts to itself, which weakens the security of the system (i.e., if you see an 'A' in the ciphertext then you know it can't be an 'A').

Keyspace (why it's huge). Choose and order 3 rotors from 5 (60 ways), choose 26 starting positions for each rotor (\(26^3=17{,}576\)), and set a plugboard that swaps letter pairs (about \(10^{14}\) possibilities). The combined space exceeds \(10^{23}\).

Strength vs. practice. Moving rotors suppressed simple frequency patterns, but design quirks and operating procedures leaked structure.

How it was broken. Analysts used cribs (predictable text like headers), the “no self-encryption” property, operator mistakes (repeating message keys, key reuse), traffic habits, captured codebooks, and electromechanical search (Polish bombas, British bombes designed by Turing and Welchman).

Takeaway. Mechanization increased complexity and throughput but not proof of security. Operational discipline and small structural properties mattered.

Successors. SIGABA (late 1930s, irregular stepping, not broken in WWII) and Fialka (1950s, 10 rotors for Cyrillic plus digits) pushed the rotor idea further until electronic cryptography replaced it.

Shannon, Perfect Secrecy, and Randomness

One-time pad (OTP).
Encrypt each byte of plaintext by taking a bitwise XOR with the corresponding byte of the key: \(C=P\oplus K\), decrypt with \(P=C\oplus K\). Perfect secrecy only if the key is truly random, at least as long as the message, independent of the plaintext, and never reused. Reuse gives \(C_1\oplus C_2=P_1\oplus P_2\).

Why OTPs are rarely used.
It is hard to generate long truly random keys, distribute and store keys (pads) that are as long as the message, avoid reuse, and keep sender/receiver perfectly synchronized.

Shannon’s contribution.
Shannon defined the two properties strong ciphers must deliver:

• Confusion (hide the key–ciphertext relationship via nonlinear substitution, e.g., S-boxes)

• Diffusion (spread each input bit widely via structured mixing).

Real ciphers apply these in simple rounds repeated many times.

Perfect vs. computational security.
Perfect secrecy: observing \(C\) reveals nothing about \(P\): \(\Pr[P=p\mid C=c]=\Pr[P=p]\). In practice, we aim for computational security— not theoretically perfect but something that has no efficient attack with realistic resources.

Random vs. pseudorandom

Random. Bits from a physical source we model as unpredictable (device noise, quantum effects).

Pseudorandom. Bits from a deterministic algorithm seeded with secret entropy. For cryptography we use a cryptographically secure pseudorandom number generator (CSPRNG): after seeding, outputs are computationally indistinguishable from true random and unpredictable without the seed.

Rule: get randomness from the OS CSPRNG (Linux getrandom(), Windows BCryptGenRandom); do not roll your own.

Shannon entropy: why it matters

What it is. A measure of unpredictability. Think “average yes/no questions to determine \(X\).”

Why you care.

• Key strength. A “128-bit key” is only as strong as the entropy used to create it. If generation had 60 bits of real uncertainty, brute-force resistance is \(2^{60}\), not \(2^{128}\).

• Destroying patterns. Plaintext (especially English) is redundant (≈1–1.5 bits/char with context). Good encryption removes that structure so ciphertext looks pattern-free and doesn’t compress.

• Sanity checks. If ciphertext shows obvious biases, repeats, or compresses well, entropy wasn’t effectively delivered to the output—design or implementation is suspect.

Key points

• OTP proves perfect secrecy in theory; logistics make it rare.

• Modern ciphers rely on confusion + diffusion across repeated rounds.

• Use the OS CSPRNG; randomness quality sets the floor on security.

• Shannon entropy is your measure for unpredictability: enough entropy in keys, and ciphertext that looks, and behaves, random to any efficient test.

Modern Symmetric Cryptography

Big picture

• Goal: Understand the structure of modern symmetric ciphers and how to use them. Most breakage is misuse (wrong mode, reused per-message input), not broken ciphers.

• Two families: Block ciphers (encrypt fixed-size blocks) and stream ciphers (keystream ⊕ plaintext).

Block ciphers

• Definition: A keyed permutation on \(n\)-bit blocks; different keys give different permutations.

• State & rounds: Treat the block as a state (bytes). Apply the same round repeatedly. A key schedule derives per-round round keys -- the key used for that round.

• Security idea: Nonlinearity + mixing, applied over several rounds, wipes out simple linear relations between input, key, and output bits within the block.

Substitution–permutation networks (SPNs)

• Pattern: Substitute bytes via small lookup tables (S-boxes), mix/permute to spread changes, then XOR a round key: \(\text{state}\leftarrow \text{state}\oplus K_i\).

• Decryption: Apply inverse substitution and inverse mixing with round keys in reverse order.

• Example: AES.

Feistel networks

• Pattern: Split block \((L_i,R_i)\). One round: \[L_{i+1}=R_i,\qquad R_{i+1}=L_i \oplus F(R_i,K_i).\]

• Property: Always invertible even if \(F\) is not; decryption reuses \(F\) with round keys reversed.

• Example: DES.

DES and 3DES (legacy but instructive)

• DES (1977): 16-round Feistel, 64-bit block, 56-bit key. Hardware-friendly design; S-boxes resist then-known attacks.

• Main issue: Key length (56-bit) is brute-forceable.

• Triple DES (EDE: encrypt-decrypt-encrypt):

  • EDE1 (1 56-bit key): \(E_K(D_K(E_K(\cdot)))\) — backward compatibility; no strength gain.

  • EDE2 (2 56-keys = 112-bit key): \(E_{K_1}(D_{K_2}(E_{K_1}(\cdot)))\).

  • EDE3 (3 56-bit keys = 168-bit key): \(E_{K_1}(D_{K_2}(E_{K_3}(\cdot)))\).

• Status: DES is a legacy algorithm; small block size, slow in software.

AES (Rijndael profile)

• Block/key sizes: 128-bit block; keys 128/192/256 bits; 10/12/14 rounds.

• Round steps: SubBytes (byte lookup table), ShiftRows (rearrange), MixColumns (mix bytes in a column), AddRoundKey (XOR).

• Why it's a good default: Strong safety margin, fast with AES-NI/ARM crypto extensions; good constant-time software exists.

Modes of operation (how to use blocks on messages)

• ECB (electronic codebook): Each block encrypted independently; identical plaintext blocks ⇒ identical ciphertext blocks; leaks structure and allows block cut-and-paste. Do not use for data.

• CBC (cipher block chaining): XOR plaintext with previous ciphertext block, then encrypt. First block uses an IV (fresh, unpredictable). Needs padding. Confidentiality only; not integrity.

• CTR (counter): Encrypt a per-message counter sequence to produce a keystream; XOR with plaintext. Unique per-message value under a key required (often called a nonce). No padding; parallelizable; random access friendly; no integrity.

• GCM (Galois counter): CTR for encryption plus a tag to detect tampering (AEAD). Requires a unique per-message value (typically 96 bits).

AEAD: Authenticated Encryption with Associated Data — encrypts and returns a tag so the receiver can reject modified ciphertexts. We will cover integrity later; read AEAD as “encryption with a built-in tamper check.”

Stream ciphers

• Model: Generate a keystream, then XOR: \(C=P\oplus \text{keystream}\) and \(P=C\oplus \text{keystream}\).

• Rule: Under one key, never reuse the per-message input that selects the keystream.

ChaCha20 (with Poly1305)

• What it does: Runs 20 rounds of add/rotate/XOR on a 512-bit internal state keyed by a 256-bit key and a per-message value to output a pseudorandom keystream; then XOR with the plaintext.

• Why used: Fast on general CPUs and embedded systems, constant-time without tables, robust side-channel profile.

• AEAD form: ChaCha20-Poly1305 (encryption + tag). Requires a unique per-message value under a key.

Quick reference

Common pitfalls

• ECB on data leaks patterns. Avoid.

• Per-message input errors:

• CBC: IV must be fresh and unpredictable.

• CTR/GCM/ChaCha20: per-message value must be unique under a key (do not reuse).

• Ignoring data limits: 64-bit blocks hit a birthday bound after about \(2^{32}\) blocks.

Minimal equations to recognize

• Feistel round: \(L_{i+1}=R_i,\; R_{i+1}=L_i \oplus F(R_i,K_i)\).

• Stream XOR: \(C=P\oplus \text{keystream}\) and \(P=C\oplus \text{keystream}\).

What to choose

• AES-GCM when AES hardware exists.

• ChaCha20-Poly1305 when it does not (or on embedded/mobile).

• CBC only with correct IV handling and a separate integrity check.

• Never ECB for real data.

Principles of Good Cryptosystems

Foundations

• Kerckhoffs’s principle: Assume the attacker knows everything except the key. Publish algorithms; keep keys secret.

• Shannon: Confusion (hide key influence) + diffusion (spread local changes). Achieved by simple rounds that substitute, mix, and add key material.

Security properties

• Random-looking ciphertext: No patterns, no bias, does not compress. If identical plaintext blocks create repeated ciphertext, the mode/usage is wrong.

• Non-invertibility without the key: Best generic attack is brute force over keys, not algebra on structure.

• Adequate key space; no weak keys: Each extra bit doubles search. (2^{128}) is beyond plausible brute force. Avoid key classes with special structure.

• Resistance across attack models: Aim for confidentiality under CPA; prefer AEAD so systems remain safe even when attackers can submit modified ciphertexts (CCA settings).

• Side-channel robustness: Defend against timing/cache, power/electromagnetic emissions, and fault attacks with constant-time code, hardware instructions, masking/blinding, and no secret-indexed table lookups.

• Composability: Security should survive real use (chunking, retries, many senders). Use AEAD, keep per-message inputs correct, and separate keys by purpose.

Practical requirements

• Efficiency: Match the hardware. AES on architectures that accelerate it; ChaCha20 where AES support is weak. Efficient designs make constant-time code feasible.

• Minimal expansion: Small, predictable overhead (e.g., a per-message input + a tag in GCM but not overhead that is a multiple of the plaintext size). Avoid custom paddings and ad-hoc headers.

• Simplicity & universality: Few controls, clear defaults, mature libraries. Use high-level AEAD APIs; do not invent modes.

• Public algorithms, open analysis: Prefer widely vetted standards. “Proprietary crypto” is a red flag.

Keys (operational reminders)

• Generation: Use the operating system's cryptographically-secure pseudorandom number generator (CSPRNG). No ad-hoc randomness.

• Handling: Protect in storage and use; rotate before per-key data limits; destroy on retirement.

• Per-message input: Treat this as a first-class parameter. CBC needs a fresh, unpredictable IV. CTR/GCM/ChaCha20 need a value unique for a given key.

Quick rules

• Prefer AES-GCM with hardware support; otherwise ChaCha20-Poly1305.

• Never use ECB for data.

• Padding is needed for ECB/CBC when message length ≠ block size; it is not needed for CTR/GCM/ChaCha20.

• Write constant-time code (no secret-dependent branches/lookups).

• Keep algorithms public; keep keys secret.

Common pitfalls

• Reusing the per-message input with the same key (CTR/GCM/ChaCha20).

• Predictable IVs in CBC

• Short keys, weak randomness, keys visible in logs/dumps.

• Secret-indexed tables causing cache leaks.

Public Key Cryptography and Integrity

Public key cryptography

• Uses two keys: public (shared) and private (kept secret).

• Goal: enable encryption and signatures without prior secret exchange.

One-way functions

• Easy to compute in one direction, hard to reverse.

• Provide the mathematical foundation for cryptography.

Trapdoor functions

• One-way functions with a secret “trapdoor” that makes inversion easy.

• Example: factoring (if one factor is known, the other is trivial).

• Example: discrete logarithm problem.

Origins

• Can two parties communicate securely without sharing a key first?

Why not use public key for everything?

• Performance: far slower than symmetric ciphers.

• Ciphertext expansion: ciphertexts larger than plaintexts.

• Security: raw RSA/ECC is unsafe without padding/schemes.

• Public key is used for key exchange and signatures, not bulk encryption.

RSA and ECC

RSA basics

• Security based on difficulty of factoring large numbers.

• Key generation: choose primes \(p, q\); compute \(n = pq\), and exponents \(e, d\).

• Encryption: \(C = P^e \bmod n\); Decryption: \(P = C^d \bmod n\).

Elliptic Curve Cryptography (ECC)

• Uses algebra on elliptic curves instead of integers.

• Provides the same security as RSA with much smaller key sizes.

• Widely used in practice, especially in TLS and mobile devices.

• Limitations

• Raw RSA is insecure; requires padding (e.g., OAEP).

• Mainly used for exchanging keys or signatures, not bulk data.

• ECC has become a preferred alternative in many systems because it provides equivalent security with much shorter key lengths.**

Hash Functions

Hash function

• Maps arbitrary input to fixed-size output.

• Goal: provide fingerprints of data for comparison or verification.

Properties

• Deterministic, fast, preimage-resistant, collision-resistant, avalanche effect.

SHA family

• Widely used cryptographic hash functions (SHA-2, SHA-3).

Applications

• Integrity checks, digital signatures, password storage.

Entropy

• Shannon entropy measures unpredictability in data.

• Goal: ciphertext and keys should appear random (high entropy).

Integrity Mechanisms

Message Authentication Codes (MACs)

• Provide integrity + authenticity using a shared secret.

• HMAC: standardized in RFC 2104; uses hash + key with inner/outer pads.

• CMAC: NIST SP 800-38B; block cipher in CBC mode, last block is MAC.

• Goal: detect modification and confirm source when parties share a secret.

AEAD (Authenticated Encryption with Associated Data)

• Combines encryption and integrity in one operation.

• Examples: AES-GCM, ChaCha20-Poly1305.

• Goal: provide confidentiality + integrity in one step.

Digital Signatures

• Provide integrity, authenticity, and non-repudiation.

• Basic idea: sign a hash with private key; verify with public key.

• Real-world schemes: RSA-PSS, ECDSA, EdDSA.

• Goal: prove origin and protect against forgery.

Why hashes are involved

• Efficiency: sign a digest instead of entire message.

• Security: avoids structural weaknesses in raw messages.

MACs vs. Signatures

• MACs: symmetric, efficient, no non-repudiation.

• Signatures: asymmetric, slower, provide non-repudiation.

Diffie-Hellman Key Exchange

Core question : How can two parties who have never met agree on a shared secret?

Basic process

• Alice and Bob exchange values derived from private exponents.

• Both compute the same shared secret without revealing private keys.

Security: Relies on hardness of the discrete logarithm problem.

Elliptic Curve Diffie-Hellman (ECDH)

• Uses elliptic curve multiplication instead of exponentiation.

• Smaller keys, faster computation, same security.

• ECDH is the dominant form of Diffie-Hellman used in

• modern TLS.

Limitation: Provides secrecy but not authentication (man-in-the-middle possible).

Putting It All Together

Hybrid cryptosystem

• Combines public key and symmetric crypto.

• Goal: public key establishes a session key; symmetric cipher encrypts data efficiently.

Long-term keys

• Persistent key pairs tied to identity (e.g., server’s RSA/ECC keys).

• Goal: prove who you are over time.

Ephemeral keys

• Generated per session and discarded.

• Goal: ensure each session has unique secrets.

Forward secrecy

• Old sessions stay protected if long-term keys are later compromised.

• Achieved with ephemeral DH/ECDH.

Digital certificates (X.509v3)

• Bind public keys to identities.

• Issued by certificate authorities (CAs).

• Contain subject, key, validity, issuer, signature, and extensions.

• Goal: provide trusted association of a public key with an identity.

Root certificates and trust stores

• Root certificates are self-signed (signed by the CA itself).

• Stored in OS/browser trust stores (macOS/iOS Keychain, Windows Cert Manager, Android system store, Linux CA bundles).

• Goal: establish trusted anchors for certificate chains.

Certificate verification process

1. Receive certificate and intermediates.

2. Check validity dates.

3. Build chain to a root.

4. Verify signatures at each link.

5. Ensure root is in trust store.

6. Confirm hostname matches certificate subject.

7. Optionally check revocation.

8. Verify server controls corresponding to the private key.

Protocols in practice

• TLS: certificates for authentication, ephemeral DH/ECDH (Diffie-Hellman/Elliptic Curve Diffie-Hellman) for key exchange, symmetric cipher (AES-GCM or ChaCha20-Poly1305) for data, AEAD for integrity. (see the more detailed discussion, below).

• PGP: sender generates session key, encrypts with recipient’s public key, uses symmetric cipher for data.

Quantum Attacks and Post-Quantum Cryptography

• Quantum computers: Use principles of quantum mechanics to process information in new ways. They are still experimental and not yet capable of breaking deployed systems, but they raise future risks.

• Quantum computers → potential threat to public key systems in the future.

• Shor’s algorithm: Shows that RSA, Diffie-Hellman, and elliptic-curve cryptography could all be broken if large-scale quantum computers become practical.

• Grover’s algorithm: Speeds up brute-force search, reducing the effective strength of symmetric keys. Symmetric systems remain safe with longer keys (for example, AES-256).

• Post-quantum cryptography (PQC): New cryptographic methods designed to resist both classical and quantum attacks. Students do not need to memorize specific algorithm names, just understand that replacements for RSA and ECC are being standardized.

Code Signing and Software Integrity

Code signing

• Uses digital signatures to ensure code comes from a known publisher and has not been modified.

• Verifies authenticity (origin) and integrity (unchanged), but not whether code is safe or bug-free.

How it works

• Developer computes a hash of the executable, signs it with a private key, and embeds signature + certificate.

• OS verifies the certificate chain and recomputes the hash to check for tampering.

Per-page hashes

• Windows and Apple systems sign catalogs of per-page hashes.

• At runtime, OS checks hashes only for pages loaded into memory.

• Ensures ongoing integrity with less performance cost.

TLS (Transport Layer Security)

TLS handshake goals

• Authenticate the server (with a certificate).

• Agree on a shared session key securely.

• Ensure confidentiality and integrity of later traffic.

Steps (simplified)

1. ClientHello / ServerHello: pick versions and cipher suites.

2. Certificate exchange: server sends certificate; client verifies chain.

3. Key exchange: usually ephemeral ECDH (Elliptic Curve Diffie-Hellman with public/private keys generated spontaneously for this session), which produces a shared secret.

4. Key derivation: TLS uses HKDF to expand the shared secret into session keys.

5. Handshake finished: each side proves it derived the same session key.

6. Secure channel: traffic is encrypted and authenticated with a symmetric cipher (e.g., AES-GCM or ChaCha20-Poly1305).

Key properties

• Forward secrecy: ephemeral keys prevent past sessions from being decrypted if the long-term key leaks.

• Integrity: AEAD modes provide confidentiality + authentication.

• Trust: relies on certificates and CAs as root anchors.

Reminders

• Session key: a temporary symmetric key used for one communication session.

• HKDF: HMAC-based Key Derivation Function; turns a shared secret into multiple usable keys.

• AEAD: Authenticated Encryption with Associated Data; ensures both confidentiality and integrity of encrypted traffic.

Key Points

• Public key cryptography enables encryption and signatures without prior key sharing.

• One-way and trapdoor functions form the foundation of RSA and ECC.

• Hash functions provide integrity; must be preimage- and collision-resistant.

• MACs ensure integrity with shared secrets; digital signatures add non-repudiation.

• Non-repudiation means a signer cannot later deny creating a valid digital signature.

• Diffie-Hellman (and ECDH) enable shared secrets without prior contact; ephemeral keys add forward secrecy.

• Digital certificates and trust stores bind public keys to identities via CAs.

• Code signing ensures software authenticity and integrity

• TLS combines certificates, ephemeral key exchange, and symmetric AEAD encryption to secure web traffic.

• Quantum computers threaten RSA, Diffie-Hellman, and ECC (Shor’s algorithm), but not symmetric ciphers if key sizes are increased (Grover’s algorithm).

• Post-quantum cryptography aims to replace vulnerable public key systems with quantum-resistant alternatives.

Authentication

Core Concepts

Identification, Authentication, Authorization
Identification is claiming an identity (such as giving a username). Authentication is proving that claim (such as showing a password or key). Authorization comes afterward and determines what actions the authenticated party may perform.

Pre-shared keys and Session keys
A pre-shared key is a long-term secret shared in advance between two parties and often used with a trusted server. A session key is temporary and unique to one session, which reduces exposure if the key is compromised.

Mutual authentication
Protocols often require both sides to prove they know the shared secret, not just one. This ensures that neither side is tricked by an impostor.

Trusted third party (Trent)
Some protocols rely on a trusted server that shares long-term keys with users and helps them establish session keys with each other.

Nonces, Timestamps, and Session identifiers
These are ways to prove freshness:

• Nonces are random values used once.

• Timestamps prove that a message is recent.

• Session identifiers tie all messages to a specific run of a protocol.

Replay attack
An attacker may try to reuse an old ticket or session key. Without freshness checks, the receiver cannot tell the difference and may accept stale credentials.

Symmetric Key Protocols

These use a trusted third party (Trent) to distribute or relay session keys. Alice asks Trent for a key to talk to Bob, Trent provides one (encrypted with Alice's secret key) along with a ticket for Bob. The ticket contains the same session key encrypted with Bob's key. It's meaningless to Alice but she can send it to Bob, who can prove that he was able to decrypt it.

Needham–Schroeder
Adds nonces to confirm that a session key is fresh. Alice asks Trent for a key to talk to Bob and includes a random number (a nonce) in the request. Trent provides the session key along with a ticket for Bob. Alice knows it's a fresh response when she decrypts the message because it contains the same nonce. Weakness: if an old session key is exposed, an attacker can replay a ticket and impersonate Alice. Vulnerable if old session keys are exposed.

Denning–Sacco
Fixes the replay problem of an attacker replaying part of the protocol using an old compromised session key by using timestamps in tickets so Bob can reject replays. Bob checks that the timestamp is recent before accepting. This blocks replays but requires synchronized clocks.

Otway–Rees
Uses a session identifier carried in every message. Nonces from Alice and Bob, plus the identifier, prove that the session is unique and fresh. No synchronized clocks are required.

Kerberos

Kerberos is a practical system that puts the Denning–Sacco idea into operation: it uses tickets combined with timestamps to prevent replay attacks. Instead of sending passwords across the network, the user authenticates once with a password-derived key to an Authentication Server (AS). The AS returns a ticket and a session key for talking to the Ticket Granting Server (TGS).

With the TGS ticket, the user can request service tickets for any server on the network. Each service ticket contains a session key for the client and the server to use. To prove freshness, the client also sends a timestamp encrypted with the session key. The server checks the timestamp and replies with T+1.

This structure allows single sign-on: after authenticating once, the user can access many services without re-entering a password. Kerberos thus combines the principles of Denning–Sacco with a scalable ticketing infrastructure suitable for enterprise networks.

Properties:

• Tickets contain session keys.

• Passwords never travel on the network.

• Timestamps prevent replay.

• Widely used in enterprise single sign-on.

Public Key Authentication

Public key cryptography removes the need for Trent. If Alice knows Bob’s public key, she can create a session key and encrypt it for Bob. Certificates bind public keys to identities, solving the problem of trust. In TLS, which we studied earlier, the server’s certificate authenticates its key. An ephemeral exchange (e.g., Diffie-Hellman) creates fresh session keys that ensure forward secrecy: past sessions remain secure even if a long-term private key is later stolen.

Password-Based Protocols

PAP (Password Authentication Protocol)
The client sends the password directly to the server. This is insecure because the password can be intercepted and reused.

CHAP (Challenge–Handshake Authentication Protocol)
The server sends the client a random value called a nonce. The client combines this nonce with its password and returns a hash of the result. The server performs the same calculation to verify it matches. The password itself never crosses the network, and replay is prevented because each challenge is different. CHAP still depends on the password being strong enough to resist guessing. Unlike challenge-based one-time passwords (covered later), CHAP relies on a static password reused across logins, not a device that generates one-time codes.

How Passwords Are Stored

Systems do not store passwords in plaintext. Instead, they store hashes: one-way transformations of the password. At login, the system hashes the candidate password and compares it to the stored value. This prevents an immediate leak of all passwords if a file is stolen, but the hashes are still vulnerable to offline guessing.

Weaknesses of Passwords

Systems do not store passwords in plaintext because that would reveal every user’s secret to anyone who obtained the file. Instead, they store hashes of passwords and compare hashes at login.

Online vs. offline guessing
Online guessing means trying passwords directly against a login prompt. Defenses include rate-limiting and account lockouts. Offline guessing happens if an attacker steals the password file; they can test guesses at unlimited speed with no lockouts, which is much more dangerous.

Dictionary attack
The attacker tries a large list of likely passwords. Online, this means repeated login attempts. Offline, it means hashing guesses and comparing against stored hashes.

Rainbow table attack
The attacker precomputes tables of password→hash pairs for a given hash function. A stolen password file can be cracked quickly with a lookup. Rainbow tables only work if hashes are unsalted.

Credential stuffing
Attackers take username/password pairs stolen from one site and try them against other services, hoping users have reused the same password.

Password spraying
Instead of many guesses against one account, attackers try one or a few common passwords across many accounts, avoiding lockouts.

Mitigations

Defenses focus on making stolen data less useful and slowing attackers.

Salts
A random value stored with each password hash. Two users with the same password will have different hashes if their salts differ. Salts make rainbow tables impractical.

Slow hashing functions
Deliberately expensive functions (bcrypt, scrypt, yescrypt) make each hash slower to compute, which hinders brute-force guessing but is barely noticeable for a user login.

Transport protection
Passwords should always travel over encrypted channels (TLS) to prevent interception.

Multi-factor authentication
A second factor (OTP, push, passkey) prevents a stolen password from being enough on its own.

Password policies
Block weak or previously breached passwords, enforce rate limits, and monitor for unusual login activity.

One-Time Passwords (OTPs)

Static passwords can be replayed. One-time password systems generate a new password for each login. The goal is to never reuse a password.

There are four main forms of one-time passwords:

1. Sequence-based: derived from repeatedly applying a one-way function.

2. Challenge-based: derived from a random challenge from the server and a shared secret.

3. Counter-based: derived from a shared counter and a secret.

4. Time-based: derived from the current time slice and a secret.

S/Key (sequence-based)
S/Key creates a sequence of values by starting from a random seed and applying a one-way function to each successive value. The server stores only the last value in the sequence. At login, the user provides the previous value, which the server can verify by applying the function once. Each login consumes one value, moving backward through the sequence. Even if an attacker sees a value, they cannot work out earlier ones because the function cannot be reversed.

Challenge-based OTP
The server issues a fresh challenge, and the user’s token or app computes a one-time response from the challenge and a secret. Replay is useless because each challenge is unique. This differs from CHAP: in CHAP the secret is a static password reused across logins, while in challenge-based OTPs the secret is stored in a device that proves possession.

HOTP (counter-based)
The server and client share a secret key and a counter. Each login uses the next counter value to generate a code with HMAC. Both sides must stay roughly in sync.

TOTP (time-based)
Like HOTP, but the counter is the current time slice (commonly 30 seconds). Codes expire quickly, making replays useless. Widely used in mobile authenticator apps (like Google Authenticator).

Multi-Factor Authentication (MFA)

MFA requires factors from different categories: something you know (password), something you have (token or phone), and something you are (biometrics).

One-time passwords (OTPs)
Codes generated by a device or app that prove you have a specific token or phone. They are short-lived and cannot be reused, making them a common possession factor.

Push notifications
Send a prompt to the user’s phone but are vulnerable to MFA fatigue, where attackers flood the user with requests hoping for one accidental approval.

Number matching
Improves push MFA by requiring the user to type in a number shown on the login screen, linking the approval to that specific login attempt.

--

Passkeys

MFA improves security but still relies on passwords as one factor, and phishing can sometimes bypass second factors. Passkeys eliminate passwords entirely. Each device generates a per-site key pair: the private key stays on the device, and the public key is stored with the service. At login, the device signs a challenge with the private key. Passkeys are unique per site, cannot be phished, and can be synchronized across devices.

Adversary-in-the-Middle Attacks

An adversary-in-the-middle sits between a client and a server, relaying and possibly altering traffic.

Defenses:

• Use TLS to encrypt and protect the channel.

• Verify the server with certificates to prevent impersonation.

• Use freshness checks (nonces, timestamps, identifiers) to block replay.

• Issue short-lived codes and tokens so intercepted data quickly expires.

• Train users to recognize and reject suspicious prompts, such as unexpected push notifications. ˜

Biometrics TBD