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: Wed Sep 30 20:09:54 2026

Week 1: Foundations of Computer Security

Focus on distinguishing related concepts and understanding how they fit together. The dates, damage totals, and vendor-specific names in the lecture notes provide context, but are not things you are expected to remember.

Security Properties

The CIA triad identifies three primary security properties:

• Confidentiality restricts access to information so that only authorized people and processes can view it.

• Integrity ensures that data and systems remain accurate and that only authorized parties can change them.

• Availability ensures that systems and data remain usable when needed.

Confidentiality and Related Concepts

Privacy, anonymity, and secrecy are related to confidentiality, but each has a different focus:

• Privacy governs how personal information is collected, used, stored, and shared.

• Anonymity separates an identity from an observable action.

• Secrecy deliberately conceals information and may conceal its existence.

Integrity

Integrity applies to data, its source, and the system processing it:

• Data integrity protects information against unauthorized modification or deletion.

• Origin integrity protects the connection between information and its asserted source.

• System integrity provides confidence that hardware, software, and processes continue to operate as intended.

Authenticity and Accountability

Authenticity provides evidence that a person, system, or message is genuine. Data integrity asks whether the content changed. Authenticity asks whether the claimed source is genuine, so it overlaps with origin integrity.

Accountability connects actions to the people or systems responsible for them.

Availability and Denial of Service

A denial-of-service (DoS) attack targets availability by making a system unavailable or too slow to be useful. A distributed denial-of-service (DDoS) attack sends traffic or requests from many systems at once.

Security System Goals

Security controls support three operational goals:

1. Prevention attempts to stop an attack or failure before it succeeds.

2. Detection identifies and reports attacks, attempted attacks, and unexpected behavior.

3. Recovery restores systems and operations after an attack or failure.

No one goal replaces the others. Prevention can fail, detection does not repair damage, and recovery is harder when an incident was never detected.

Defense in depth uses several independent layers of protection so that the failure of one control does not compromise the entire system. The layers may prevent, detect, limit, or help recover from the same event.

Policies, Mechanisms, and Assurance

Securing a system requires two separate decisions: what is allowed and how that decision is enforced.

• A policy defines which actions are allowed.

• A mechanism enforces a policy.

Mechanisms fall into two groups:

• Technical mechanisms use hardware or software to enforce a policy, including access controls, cryptography, and intrusion detection.

• Procedural mechanisms rely on people following a defined process, including identity checks, audits, and separation of duties.

Every mechanism depends on assumptions about the system and its environment. When an assumption is wrong, the mechanism may stop enforcing its policy without an obvious sign of failure.

Assurance measures the confidence that a system correctly enforces its policies. That confidence comes from evidence gathered through design reviews, testing, code audits, and penetration testing.

Security engineering applies these ideas throughout a system’s design, implementation, and operation. It treats security as an ongoing engineering problem involving cost, usability, evolving threats, and recovery.

The Trusted Computing Base (TCB) contains the hardware, firmware, and software that must work correctly for the system’s security rules to hold. A trust boundary is a point where data or control passes between parts of a system that are trusted differently.

The supply chain includes the people, tools, vendors, and components used to build and deliver a system. Supply chain security protects that process, including software dependencies, build systems, and update channels.

Security theater describes a measure that creates the appearance of protection without meaningfully reducing risk. Misaligned incentives arise when the party deciding how much security to buy does not bear the full cost of failure.

Risk Analysis

Risk analysis identifies what needs to be protected, determines how it could be harmed, assesses the likelihood and impact of that harm, and prioritizes ways to address the risk. The sequence is:

asset -> threat -> vulnerability -> attack vector -> security control -> residual risk

Each term in the sequence has a specific role:

• An asset is something valuable that must be protected.

• A threat is a circumstance or event with the potential to cause harm.

• A vulnerability is a weakness that could allow a security property to fail.

• An attack vector is the path or method used to gain access or produce an effect.

• A security control, or countermeasure, reduces the likelihood or impact of harm.

• Residual risk is the risk that remains after controls are applied.

A threat model is a structured account of how a specific system could be harmed. Building one means breaking the system into its parts, identifying its trust boundaries, and asking what could go wrong within each part and at each boundary. The model records what must be protected, who or what could cause harm, which controls reduce the risk, and the assumptions behind those decisions.

Responses to an identified risk fall into four categories:

• Mitigate a risk by reducing its likelihood or impact, although mitigation still leaves residual risk.

• Avoid a risk by stopping the activity that creates it, which may also eliminate a useful service.

• Transfer part of a risk through insurance, contracts, or outsourcing. Transfer may shift financial loss without shifting operational damage, legal responsibility, or reputational harm.

• Accept a risk when it falls within the organization’s tolerance or when further reduction would cost more than the expected harm.

Vulnerabilities, Exploits, and Attacks

These terms describe different stages of a security problem:

• A bug is a defect in hardware or software. Some bugs create vulnerabilities, but vulnerabilities may also result from design choices, configuration, or human behavior.

• A vulnerability is a weakness that could lead to a security failure.

• An exploit is code, a tool, or a technique that takes advantage of a vulnerability.

• An attack is a deliberate attempt to compromise a system.

• A security incident is an event that actually or potentially jeopardizes a security property or violates a policy.

• A data breach is an incident involving unauthorized access to or disclosure of data.

An incident does not have to be a data breach. An availability failure can be a serious security incident even when no information is disclosed.

Spectre, Meltdown, and Rowhammer demonstrate that vulnerabilities can also exist in hardware, where performance features and physical behavior may undermine protections that software relies on.

Exfiltration is the unauthorized transfer of data from a system to a location controlled by an attacker. It is an attack action that compromises confidentiality.

Kinds of Attack

The terms below mix objectives and methods, and most incidents involve several at once:

• Ransomware encrypts data or otherwise disables access to it and demands payment for restoration.

• Extortion uses a threat, such as publishing stolen data, to demand payment or another concession.

• Double extortion combines encryption with a threat to publish stolen data. Backups can restore encrypted files, but they cannot undo the public release of information.

• A wiper is malicious software designed to erase data. Its goal is destruction rather than payment.

• Denial of service makes a system unusable by exhausting a finite resource or triggering a crash.

• Resource hijacking runs the attacker’s software on someone else’s computer, making the machine itself the target rather than its data.

• Impersonation uses stolen or forged credentials to act as another party. Credential stuffing is one form, replaying username and password pairs from an earlier breach against unrelated sites.

• Social engineering targets a person rather than software.

Attack Surface

An attack surface is the complete set of places where an attacker might attempt to enter a system or produce an effect. A single vulnerability may be reachable through several attack vectors, so closing one path does not necessarily remove the vulnerability. Patching can repair a vulnerability while leaving the affected service reachable. Moving a service to a provider can reduce the locally managed attack surface while retaining dependencies on the provider’s security.

Hardening reduces the attack surface by removing unused software, disabling unnecessary services, closing ports, and changing insecure defaults. A loosening guide describes the consequences of enabling features that a secure default configuration leaves disabled. Forgotten accounts, applications, services, and permissions remain part of the attack surface even when no one remembers creating them.

An air gap removes direct network connectivity and requires a controlled process to cross the boundary. A Sensitive Compartmented Information Facility (SCIF) controls physical access, electronic devices, sound leakage, and procedures. Some SCIFs also include shielding against radio emissions. Neither control eliminates risks from people, removable media, maintenance, or the supply chain.

Human Factors

Social engineering manipulates a person into providing information or access. Bribery, blackmail, recruitment, and honest mistakes show why human factors cannot be addressed by awareness training alone. Controls must also limit what one person can do, record sensitive actions, and provide a reliable recovery path.

Threats and Threat Actors

A threat may arise from an adversary, an accident, an equipment failure, or a natural event. A threat actor, also known as a threat agent, is a person, group, organization, or state that might carry out an adversarial threat.

Four threat classes describe the effect on a system:

• Disclosure exposes information without authorization.

• Deception causes false information to be accepted as true.

• Disruption interrupts or degrades correct operation.

• Usurpation gives an unauthorized party control of a system or resource.

The Internet as a Risk Amplifier

The Internet amplifies risk through several properties:

• Action at a distance removes the need for physical presence.

• Anonymity and obfuscation make an attacker’s location and identity difficult to determine.

• Global reach places attackers, victims, infrastructure, and money in different jurisdictions.

• Automation at scale allows a single attack to be launched against millions of systems.

• Shared code turns one vulnerability into many potential targets.

• Asymmetric force and effort require defenders to protect every reachable path, while an attacker needs only one that works.

• Lack of distinction means malicious activity can resemble legitimate use.

A botnet is a collection of compromised devices controlled as a group. Its command-and-control (C2) infrastructure distributes instructions and receives results.

Adversaries

An adversary is the person, group, organization, or state pursuing an objective through an attack. Five axes provide a useful description:

1. Goals describe the result the adversary seeks.

2. Risk tolerance describes the exposure and cost the adversary will accept.

3. Resources describe the available money, time, personnel, and infrastructure.

4. Expertise describes the adversary’s ability to understand systems and develop attacks.

5. Level of access describes what the adversary already holds, from none, to a network path from outside, to physical proximity, to the legitimate credentials of an employee or contractor.

A threat matrix emphasizes expertise and focus. Focus ranges from opportunistic, where an attacker searches broadly for any vulnerable target, to targeted, where an attacker pursues a selected victim and adapts when defenses hold.

Common labels identify how adversaries operate or what motivates them:

• Hackers probe systems out of curiosity, for profit, or professionally. White hats act under authorization, black hats act without authorization for harmful purposes, and gray hats act without authorization but may claim a defensive purpose.

• Criminal groups conduct fraud, ransomware, extortion, and the sale of access or attack services.

• Malicious insiders intentionally abuse legitimate access they already hold.

• Hacktivists attack to advance a political or social message.

• Industrial spies steal trade secrets for competitors or governments.

• Law enforcement and intelligence agencies seek access for investigation, surveillance, or state objectives under the laws governing them.

• Nation-states fund operations in support of military, intelligence, diplomatic, or economic objectives.

• Script kiddies are low-skilled attackers who rely on tools and instructions created by others.

An advanced persistent threat (APT) is a well-resourced adversary or cluster of actors that pursues significant objectives over an extended period and seeks to maintain or regain access.

Operations, Countermeasures, and Attribution

Cyber espionage primarily seeks information. Cyber warfare primarily seeks effects such as disruption, damage, or loss of control, although there is no universally accepted boundary between the two.

GPS jamming overwhelms satellite signals, preventing a receiver from determining a reliable position or time. GPS spoofing transmits false navigation signals that a receiver accepts as genuine.

Government- and provider-led takedowns operate under legal authority to seize or redirect attacker infrastructure. A private hack-back is an offensive action taken by a victim against an apparent attacker. It creates legal and operational risks because the apparent source may be an innocent compromised system.

Attribution is the process of determining who conducted an operation. Reused tools, compromised infrastructure, false flags, and incomplete evidence make attribution uncertain. Analysts therefore compare tactics, techniques, and procedures (TTPs) across incidents rather than relying solely on actor names. Tactics are objectives, techniques are methods, and procedures are specific implementations.

Tracking Vulnerabilities

Defenders need four types of information about a vulnerability: a shared identifier, a measure of technical severity, evidence of exploitation, and a way to determine whether the affected product is in use. No single source provides all four, so vulnerability management combines identifiers, severity scores, exploitation data, and local system information.

Two tracking concepts form the core vocabulary:

• Common Vulnerabilities and Exposures (CVE) provides a shared identifier for a vulnerability.

• Common Vulnerability Scoring System (CVSS) rates a vulnerability’s technical severity under stated assumptions.

CVE identifies which vulnerability is being discussed. CVSS describes its technical severity, but it does not measure risk to a particular organization.

Two common sources add information beyond CVE identifiers and CVSS scores:

• The National Vulnerability Database (NVD) adds product, severity, and classification data to CVE records.

• The Known Exploited Vulnerabilities (KEV) catalog records vulnerabilities with reliable evidence of exploitation in the wild.

Technical severity does not determine organizational risk on its own. Defenders must also consider whether the product is installed, whether it is exposed, what asset it supports, whether exploitation is occurring, and which controls already protect it.

Vulnerability tracking usually follows this sequence, although attackers and defenders do not wait for the steps to happen in order:

1. Discovery occurs when someone finds a vulnerability.

2. Reporting brings the vulnerability to the vendor or another coordinating organization, usually with time to prepare a fix before public release. This practice is called coordinated disclosure.

3. Investigation confirms the vulnerability and identifies the affected products and versions.

4. Assignment gives the vulnerability a CVE identifier.

5. Publication adds the CVE record to the public catalog.

6. Scoring describes technical severity with CVSS.

7. Enrichment adds product, weakness, and other contextual information.

8. Mitigation supplies and applies a patch or workaround.

9. Exploitation tracking records confirmed exploitation or estimates its likelihood.

A zero-day vulnerability is previously unknown to the vendor or defenders. A zero-day attack exploits that vulnerability before defenders have time to prepare. The absence of a patch does not by itself make a vulnerability a zero-day.

What You Don’t Need to Study

These exclusions apply to the introductory material. Topics developed in later lectures, including code signing and SIM swapping, are covered by those lectures’ study guides. The lecture notes include material that establishes scale, provides context, or introduces topics covered later in the course. You don’t need to study the following:

• Dates, payment amounts, damage estimates, victim counts, and numbers of affected systems. They establish scale and chronology rather than define concepts.

• Names, timelines, attribution claims, and technical details of individual incidents, including the case-study sidebars. Understand the security principle each one illustrates without memorizing which organization or country was involved.

• Names of specific malware, such as Mirai and Stuxnet, along with ransomware groups, access brokers, intelligence contractors, security vendors, and stolen government tools.

• How Spectre, Meltdown, and Rowhammer work. They appear only to show that vulnerabilities can exist in hardware.

• How injection attacks, ransomware, and AI attacks work. Each has its own lecture later in the course. Know the distinctions among ransomware, extortion, and double extortion, including why backups do not prevent the disclosure of stolen data.

• Technical details of programmable logic controllers (PLCs). They appear only as background for the industrial-control examples.

• Tools, frameworks, and laws mentioned in passing: Metasploit, the ATT&CK framework, and the Computer Fraud and Abuse Act.

• The history of CERT, and which organizations run CVE, NVD, KEV, and CVSS. Know what each tracking system is for, how the four differ, and why technical severity alone does not determine organizational risk.

• Specific CVE identifiers, CVSS score ranges, and the exact labels or order of the vulnerability tracking stages. Know that a vulnerability moves from discovery through reporting, identification, scoring, and mitigation, and that exploitation can happen at any point along the way.

• Vendor-specific mappings among APT numbers, weather names, animal names, and newer Google names. They demonstrate the absence of a standard naming system.

• EPSS and LEV. They illustrate how defenders estimate exploitation beyond confirmed reports. You don’t need their names, calculations, or operational details.

Week 2: Symmetric Cryptography

Focus on what each cipher did, why it was broken, and what the break taught. The dates, names of people, and mechanical details in the lecture notes provide context, but are not things you are expected to remember.

Goals and Terms

Cryptography serves four goals:

1. Confidentiality keeps a message hidden from anyone not authorized to read it.

2. Authentication verifies the origin of a message or the identity of a party.

3. Integrity ensures that a message has not been modified.

4. Non-repudiation prevents a sender from denying that they sent a message.

In this section, we’re concerned about confidentiality.

The basic vocabulary applies to every cipher:

• Plaintext is the readable message and ciphertext is its encrypted form. Encryption and decryption convert between them.

• A cipher is the algorithm that performs the transformation. A key is the secret value that controls how the cipher transforms the data.

• A cryptosystem is the cipher together with the keys and the procedures for generating, distributing, and using them.

• Symmetric encryption uses the same key to encrypt and decrypt. Asymmetric encryption, covered later, uses different keys.

• Cryptography is the design of secure systems, cryptanalysis is the breaking of them, and cryptology covers both.

The keyspace is the set of all possible keys, and a brute-force attack tries every key in it. A large keyspace is necessary for security, but never enough, because even ciphers with an enormous keyspace were broken without searching it.

Kerckhoffs’s Principle

Kerckhoffs’s Principle states that a cryptosystem must remain secure when the adversary knows everything about it except the key. Algorithms become known through reverse engineering, defection, and capture; a system that depends on the secrecy of its method is permanently broken once the method is known, whereas a key can be replaced. Open designs also allow weaknesses to be found and fixed before an adversary finds them.

Schneier’s Law is the observation that anyone can design a cipher that they themselves cannot break. Confidence in a cipher’s strength is established only by the failure of other people, who want to break it, to do so over a long period of time.

Classical Ciphers

Classical ciphers are the hand ciphers used before the twentieth century. Nearly all of them are one of two kinds:

• A substitution cipher replaces each symbol with another symbol.

• A transposition cipher keeps the symbols and rearranges their order.

Substitution and Frequency Analysis

The Caesar cipher shifts every letter by a fixed amount, and the shift is the key. A monoalphabetic substitution cipher generalizes this to any fixed mapping from plaintext letters to ciphertext letters, giving \(26!\) possible keys.

Given enough ciphertext, frequency analysis can break a monoalphabetic substitution cipher. Letters and pairs of letters (bigrams) occur with characteristic frequencies in every language, and a fixed substitution relabels the symbols without changing those patterns. Common ciphertext symbols are candidates for common plaintext letters, while bigrams and recognizable words help confirm the mapping. The size of the keyspace is irrelevant because the attacker does not need to search it.

This attack established the goal that every later cipher pursues: ciphertext should appear statistically random, with no patterns for an analyst to measure.

Polyalphabetic Substitution

A polyalphabetic cipher changes the substitution alphabet as it moves through the message, so the same plaintext letter encrypts differently in different positions. Mixing several substitution alphabets obscures the frequency distribution of the message as a whole. The distribution reappears when an analyst isolates positions encrypted with the same alphabet.

The Alberti cipher was the first to propose this, using two concentric disks, each with an alphabet along its edge. Rotating one of the disks changed the substitution alphabet.

The Vigenère cipher uses a keyword repeated to the length of the message. The repeated keyword is the keystream, the sequence of key values applied one by one to the plaintext, and each keystream letter selects a Caesar shift for the plaintext letter beneath it. The number of letters before the keystream repeats is its period. The cipher was considered unbreakable for three centuries.

The Kasiski attack breaks it by exploiting the period. Repeated plaintext that happens to align with the same part of the keystream produces repeated ciphertext, and the distances between repeats are multiples of the period. Once the period is known, the ciphertext splits into that many interleaved Caesar ciphers, and frequency analysis solves each one. The lesson is that a key shorter than the message must repeat, and the repetition leaves a trace. A key as long as the message with no repetition would have no period, and that idea becomes the one-time pad.

Transposition

A transposition cipher, such as columnar transposition, writes the message into a grid and reads it out in an order determined by a keyword. Because the letters are unchanged, frequency analysis immediately reveals the language, and an analyst can recover the grid by trying widths and looking for columns that produce common bigrams when placed side by side.

Padding is filler added so that a message fits a required size. It appears in classical grids and in modern block ciphers, and badly designed padding can leak information.

Bigram Substitution and Combined Ciphers

Substitution hides the letters but preserves their statistics. Transposition preserves the letters but hides their positions. Two ideas resisted frequency analysis. The Playfair cipher substituted pairs of letters instead of single letters, which raised the cost of frequency analysis (the analyst must count pairs) without removing it. Ciphers that apply substitution and then transposition are stronger than either alone because each step destroys what the other preserves. Every modern block cipher substitutes large units and alternates the same two operations over many rounds.

The classical era established a short list of conclusions:

• A large keyspace is not enough.

• Ciphertext must not preserve the statistics of the plaintext.

• Repeating a short keystream or reusing the same keystream creates exploitable patterns.

• Substitution and transposition are stronger together.

• The cipher is only one part of a system that also includes keys, message formats, and operating procedures.

• Hand operation limits how complex a cipher can be.

Rotor Machines and Enigma

A rotor is a disk wired to perform a fixed substitution. A rotor machine stacks several rotors and turns them like an odometer after each letter, so the composite substitution changes with every keystroke. Its keystream, the sequence of rotor positions, has a period longer than any message, which removes the repetition that the Kasiski attack relies on.

Enigma was the German rotor machine of World War II. Its keyspace was about \(10^{23}\), and it was never broken by brute force. Its design was known to its enemies, so Kerckhoffs’s principle was satisfied; it was broken because its structure and the way it was used had flaws that the size of the keyspace did not reveal.

Information Theory and Perfect Secrecy

Claude Shannon’s 1949 paper gave cryptography a mathematical foundation.

Entropy measures the uncertainty in a random variable, in bits. A fair coin has one bit of entropy; a heavily biased coin has much less. A source with maximum entropy cannot be compressed on average without losing information. English text carries only about one bit of information per letter, and the rest is redundancy: letters that a reader could have predicted. Redundancy is what frequency analysis feeds on.

A cipher has perfect secrecy if the ciphertext reveals no information about the plaintext: the adversary’s probability estimate for every possible plaintext is the same after seeing the ciphertext as before. No amount of computing power helps, because the information is not there. Perfect secrecy concerns only the contents of the message. It does not hide the message’s length or who sent it to whom.

The One-Time Pad

The exclusive-or (XOR) of two bits is 1 when they differ and 0 when they are the same. XORing with the same value twice restores the original, and XORing anything with a random bit produces a random bit.

The one-time pad encrypts by XORing the plaintext with a key of the same length and decrypts by XORing again with the same key. It has perfect secrecy provided that three conditions hold:

1. The key is truly random and independent of the message.

2. The key is at least as long as the message.

3. The key is never reused.

Reusing a key is fatal because XORing two ciphertexts encrypted under the same key cancels the key and leaves the XOR of the two plaintexts, which the redundancy of language usually makes recoverable.

The one-time pad is impractical for most uses because it replaces the problem of sending a secret message with the problem of securely delivering a secret key of the same length. Shannon showed that this cost is unavoidable: perfect secrecy needs a key with at least as much entropy as the message.

Computational Security

Computational security means that breaking a cipher is infeasible for a bounded adversary, one with limited time, computing power, and money, even though it is possible in principle. The claim rests on two things:

1. A key long enough that exhaustive search is infeasible (an \(n\)-bit key takes \(2^{n-1}\) trials on average, and each added bit doubles the work).

2. A cipher with no structural shortcut that does better than exhaustive search.

The second can never be proved, which is why algorithms are published for analysis and systems are built so that an algorithm can be replaced. The standard is computational indistinguishability: an attacker who chooses two messages of the same length and is given an encryption of one should be unable to tell which was encrypted significantly better than by guessing.

Attack models describe what an adversary has to work with:

• A ciphertext-only attack uses intercepted ciphertext alone. Frequency analysis is the classic example.

• A known-plaintext attack also uses some plaintext and its corresponding ciphertext, such as a standard header that every message begins with.

• A chosen-plaintext attack lets the adversary get messages of their own choosing encrypted. Any system that encrypts data supplied by outsiders faces this adversary.

• A chosen-ciphertext attack lets the adversary submit ciphertexts for decryption and learn something from the result.

Modern ciphers must resist chosen-plaintext attacks at a minimum, and systems are expected to resist chosen-ciphertext attacks as well.

Confusion and Diffusion

Shannon named the two properties every practical cipher needs:

• Confusion makes the relationship between the key and the ciphertext too complicated to describe by a short equation. It comes from S-boxes, small nonlinear lookup tables.

• Diffusion spreads the influence of each plaintext bit across many ciphertext bits. It comes from permutations and linear mixing operations.

Good diffusion produces the avalanche effect: changing a single input bit flips about half of the output bits. Neither property is enough alone. A modern cipher alternates between a substitution step and a mixing step over many rounds, mixing in key material at each round. This is the structure of every modern block cipher.

Randomness

Modern cryptosystems depend on unpredictable keys and usually on fresh or unique per-message values. An adversary who can predict those values may not need to attack the cipher. Three kinds of sequences are called random:

• True random bits come from an unpredictable physical process.

• Pseudorandom bits come from a deterministic pseudorandom number generator (PRNG) that expands a short seed. Anyone who knows the seed can regenerate the sequence. Ordinary library generators are of this kind and are not suitable for secrets.

• A cryptographically secure pseudorandom number generator (CSPRNG) produces output that cannot be distinguished from true randomness or predicted from earlier output by anyone who does not know the seed.

Application code should use the operating system’s CSPRNG rather than build its own. Predictable or reused random values have broken more real systems than any weakness in a cipher: the Netscape browser, Debian’s OpenSSL, the PlayStation 3, and hundreds of thousands of Internet certificates all failed because of the random number, not the algorithm.

Block Ciphers

A block cipher encrypts a fixed-size block of bits (64 or 128) into a block of the same size. For a given key, it is a one-to-one mapping of all possible blocks. Modern block ciphers build that mapping by repeating a round many times on an internal state, with a key schedule that expands the key into a separate round key for each round.

Two structures dominate the design of block ciphers:

• A substitution-permutation network (SPN) applies an S-box substitution, a permutation or mixing step, and a round key in each round. Every step must be invertible. AES is an SPN.

• A Feistel network splits the block in half, applies a keyed function to one half, XORs the result into the other, and swaps. The round function never has to be inverted, so decryption is the same procedure with the round keys in reverse order. DES is a Feistel cipher.

DES and Triple DES

The Data Encryption Standard (DES), published in 1977, was the first public cipher standard. It has a 64-bit block, a 56-bit key, and 16 rounds. Its S-boxes turned out to resist differential cryptanalysis, an attack not published until 1990, because IBM had discovered the attack privately and designed against it.

DES failed because of its key length. A 56-bit key was brute-forced with purpose-built hardware in 1998. Its 64-bit block is a second limit: by the birthday bound, repeated blocks are expected after about \(2^{32}\) blocks, and in common modes a repeat leaks plaintext.

Triple DES (3DES) runs DES three times in an encrypt-decrypt-encrypt sequence. A meet-in-the-middle attack makes double encryption barely stronger than single, which is why three applications were needed. 3DES kept the small block, was slow, and is now disallowed.

AES

The Advanced Encryption Standard (AES) was selected in an open international competition and standardized in 2001. It is the cipher Rijndael with a 128-bit block and a 128-, 192-, or 256-bit key, using 10, 12, or 14 rounds. Each round applies four steps: SubBytes (S-box substitution, confusion), ShiftRows and MixColumns (diffusion), and AddRoundKey.

No practical attack on AES is known. It is fast in software, and most processors run it in hardware. AES is the default choice for a block cipher.

Modes of Operation

A mode of operation defines how a block cipher is applied to a message longer than one block. Choosing the wrong mode breaks the system even when the cipher is sound. The four modes below are the ones to know:

• Electronic codebook (ECB) encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks. Patterns in the data survive, and blocks can be reordered. It should not be used for data.

• Cipher block chaining (CBC) XORs each plaintext block with the previous ciphertext block before encrypting it. The first block is XORed with an initialization vector (IV), a random, non-secret block generated fresh for each message. CBC needs padding, cannot encrypt in parallel, and does not detect tampering.

• Counter (CTR) mode encrypts a sequence of counter values to produce a keystream that is XORed with the plaintext. It needs no padding and can run in parallel. The counter starts from a nonce, a number used once. CTR is malleable, as ECB and CBC are in their own ways: flipping a ciphertext bit flips the same plaintext bit, so it must be paired with authentication.

• Galois/Counter mode (GCM) is CTR mode with an authentication tag computed over the ciphertext and any associated data, header information that is authenticated but not encrypted. It is the most widely used AEAD mode.

Authenticated encryption with associated data (AEAD) produces an authentication tag along with the ciphertext so that tampering is detected. New systems should use an AEAD mode: AES-GCM where AES hardware is available, ChaCha20-Poly1305 where it is not.

The nonce or IV is part of the mode’s design, and each mode specifies what it requires. In CTR, GCM, and stream ciphers, reusing a nonce under the same key reuses the keystream, causing the one-time pad’s key-reuse failure: XORing two ciphertexts yields the XOR of the plaintexts. Common failures include using ECB for data, repeating a nonce, or failing to authenticate ciphertext.

Stream Ciphers

A stream cipher generates a keystream from a key and a nonce and XORs it with the plaintext, as a one-time pad would with a pad that a computer can generate. The keystream generator is a CSPRNG, and the cipher’s security is the generator’s security. As with CTR mode, a repeated nonce results in a repeated keystream.

ChaCha20 is the modern stream cipher, built from additions, rotations, and XORs on 32-bit words. Those operations use no lookup tables, so ChaCha20 is designed to be implemented in constant time, and it is fast on processors without AES hardware. It is used with the Poly1305 authenticator as the AEAD construction ChaCha20-Poly1305, one of the two standard cipher choices in TLS 1.3.

Cryptanalysis of Modern Ciphers

Brute force against a 128-bit key is not feasible. A cryptanalytic attack is any method that recovers the key or plaintext in fewer operations than brute force. Three families have produced results against real ciphers:

• Differential cryptanalysis studies how a difference between two plaintexts propagates into a difference between ciphertexts. It needs chosen plaintexts, and modern S-boxes are designed so that no useful difference pattern survives more than a few rounds.

• Linear cryptanalysis finds XOR relations among plaintext, ciphertext, and key bits that hold slightly more or less than half the time, and uses many known plaintexts to measure the bias.

• Side-channel attacks ignore the mathematics and measure the implementation: timing, cache access patterns, power consumption, electromagnetic emissions, or the results of induced faults. Constant-time code, hardware instructions, and masking are the defenses. Constant-time code has no branches or memory accesses that depend on secrets.

A cipher offers \(n\) bits of security when the best attack costs about \(2^n\) operations. Grover’s algorithm on a large quantum computer would halve the effective key length of a symmetric cipher, which is why AES-256 is recommended for long-lived secrets. Symmetric cryptography survives quantum computing with a longer key.

Requirements for a Secure Cryptosystem

A good cryptosystem provides security that survives disclosure of the algorithm, ciphertext that an attacker cannot tell apart from the encryption of any other message of the same length, no shortcut to the key, a key long enough to make brute force infeasible, security under chosen-plaintext and chosen-ciphertext attacks, resistance to side channels, a fresh IV or nonce for every message, and keys that are generated by a CSPRNG and handled carefully. Most of these are properties of the surrounding system rather than of the cipher, and that is where real systems fail.

What You Don’t Need to Study

The lecture notes include the material to establish context and scale that you don’t need to know:

• You will not need to encrypt or decrypt messages by hand, construct cipher tables or grids, trace data through individual rounds, or reproduce the equations for cipher modes. Know what each construction does, what security properties it provides, and why it can fail.

• Dates, the names of the people who designed or broke each cipher, and biographical details.

• The mechanics of Atbash, Playfair, and the ADFGVX encoding, and the Vigenère square as a lookup table. Know what each cipher does and why it fails, not how to run it by hand.

• Enigma’s rotor count, plugboard cabling, the arithmetic of its keyspace, how the bombe was wired, the specific flaws that let it be broken, cribs, and traffic analysis. Know that a large keyspace did not save it.

• The stories of the Polish and British breaks, and the Lorenz, Colossus, SIGABA, Fialka, and Crypto AG machines. They illustrate the principles.

• The entropy formula and its derivation. Know what entropy measures and why English has low entropy.

• The history of Vernam, Mauborgne, and Frank Miller, and the VENONA project.

• The details of the randomness failures beyond the shared lesson that the random number, not the algorithm, was the weak point. Lava lamps and quantum beacons are also background information you don’t have to know (although the lava lamp story makes for good trivia at parties).

• The internal structure of the DES round function, the AES key schedule, and the parameters of ChaCha20. RC4 and its history; know only that earlier stream ciphers had biased keystreams and were replaced.

• AES-NI and the details of cache-timing attacks on software AES. Know that most processors run AES in hardware.

• The mechanics of the meet-in-the-middle attack, Sweet32, KRACK, and the padding-oracle attacks, and the arithmetic of the birthday bound.

• The list of national-standard ciphers and everything in the appendix.

Week 3: Public Key Cryptography and Integrity

Hashes detect changes when the expected digest is trusted. Message authentication codes and digital signatures also connect data to a key holder, while certificates help establish whose public key is being used. Focus on what each mechanism establishes, what it leaves unprotected, and which trust assumptions it requires.

Integrity and Authenticity

• Integrity ensures that data has not been modified.

• Authenticity verifies that data came from the source it claims.

• Confidentiality hides content. Encryption alone does not guarantee integrity, so an encrypted message can be altered without the receiver detecting the change unless the system also checks integrity.

Hash Functions

A cryptographic hash function maps a message of any length to a fixed-size digest. It is public and takes no key, so anyone can compute it.

Be able to recognize and define these properties and explain their purpose:

• Fixed-length output means the digest has the same size regardless of the input’s length. This makes it inexpensive to store, publish, or sign, but also means collisions must exist.

• Determinism means the same input always produces the same digest, allowing repeated calculations to be compared.

• Preimage resistance means that given a digest, finding any input that produces it is infeasible. It is not a guarantee of secrecy, since guessable inputs can be found by hashing candidates.

• Second preimage resistance means that, given one message, finding a different message with the same digest is infeasible.

• Collision resistance means finding any two different messages with the same digest is infeasible, even when the attacker chooses both.

• Avalanche means even a one-bit change alters about half the digest bits on average, unpredictably.

• Efficiency means computing a digest is fast, with work roughly proportional to the input’s length.

Second preimage resistance protects an existing message against substitution. Collision resistance also prevents an attacker from preparing two messages with matching digests in advance, obtaining approval for one, and substituting the other. It is the stronger requirement because the attacker chooses both messages.

Collisions must exist because there are more possible messages than fixed-size digests. This is the pigeonhole principle. The requirement is that finding a collision be infeasible, not that collisions never occur.

For a well-designed hash with an \(n\)-bit digest, a brute-force search on an ordinary, non-quantum computer takes about \(2^n\) attempts to find a preimage or second preimage. Weaknesses in a particular hash function can allow faster attacks.

Finding any collision takes about \(2^{n/2}\) attempts, because each new message can be compared against every message already tried. This is the birthday problem. A 256-bit digest is therefore needed for 128 bits of collision resistance. The doubling applies only to collision resistance.

SHA-256 processes fixed-size blocks, mixing each block into a running value. Its final digest exposes the state needed to continue that calculation. This property enables the length-extension attack described below.

Hash functions are used to verify transfers, name content, commit to data, store passwords, link records, and find duplicates. A hash-based commitment binds an author to data to be revealed later. Concealing guessable data also requires adding secret randomness. Password storage uses deliberately expensive hashing to slow guessing.

A digest detects hostile substitution only when the expected digest is trustworthy. An attacker who can replace both a file and its published digest can make the receiver’s hash check pass.

Message Authentication Codes

A message authentication code (MAC), also called an authentication tag, is computed from a message and a secret key. A matching tag provides evidence that a key holder authenticated the message and that its bytes have not changed. A hash alone does not provide sender authentication, and checking integrity with a hash requires a trusted expected digest.

A MAC does not provide confidentiality. The tag can travel in the open, and the message remains readable unless it is also encrypted.

A length extension attack continues a hash calculation from an existing digest. With SHA-256, this makes hashing a secret key followed by the message an insecure MAC construction. An attacker who has the tag and knows or guesses the combined input length can calculate a tag for an extended message without knowing the key. The extension must account for the hash function’s padding.

HMAC is a hash-based MAC that avoids this attack by nesting two hashes, each using a differently prepared version of the key (XORing the key with two different values). The inner hash covers one key-derived block followed by the message. The outer hash covers a second key-derived block followed by the fixed-length inner digest. Continuing a hash calculation from the tag therefore does not produce a valid HMAC for a longer message.

A tag protects only the bytes included in its calculation. A manifest is a structure that contains data about the content, such as a product name, version, and file digest. Authenticating the manifest with a MAC or a signature binds those fields together, allowing changes to the release information to be detected.

Encryption without authentication leaves a message open to modification. With a stream cipher or counter mode, changing a ciphertext bit changes the corresponding plaintext bit, so an attacker who knows the message format can make a predictable change to what the receiver recovers.

Authenticated encryption with associated data (AEAD) combines encryption and authentication, including protection for associated data that remains readable. When encryption and a MAC are separate, encrypt-then-MAC authenticates the ciphertext so a receiver can reject a forgery before decrypting it. Authentication tags protect against ciphertext modification only if the receiver rejects messages whose tags fail before using the plaintext.

Shared secrets have three limitations that are relevant here:

1. Either key holder could have produced any valid tag, so a MAC gives no non-repudiation.

2. The number of pairwise keys grows quadratically with the number of parties (every pair of users needs a secret key). Each pair also needs a way to establish its initial secret securely.

3. A MAC key placed in every software installation allows anyone who extracts it to forge updates accepted by the other installations.

Public Key Cryptography

A one-way function is easy to compute and computationally infeasible to reverse. Example calculations include multiplying large primes versus factoring their product, modular exponentiation versus recovering the exponent, and elliptic curve point multiplication versus recovering the secret multiplier. Recovering the exponent is the discrete logarithm problem. Preimage resistance gives a cryptographic hash its one-way property.

A trapdoor is secret information that makes reversing a one-way function efficient. A one-way function with this property is a trapdoor function. Trapdoors provide one approach to public-key cryptography, but key agreement and signatures can use other constructions. Hash-based one-time signatures can use random secrets as a private key and their digests as the public key, without reversing the hash function.

A public-key scheme generates a mathematically related pair of keys. The public key can be distributed freely, while the private key remains secret. Recovering the private key from the public key must be computationally infeasible.

Distinguish the three public key cryptographic operations:

• Public-key encryption gives confidential delivery to one recipient, but it does not identify the sender.

• A digital signature gives publicly verifiable authentication, and it leaves the message readable.

• Key agreement establishes a shared secret, but by itself does not authenticate the participants.

The main public-key methods we covered are:

• RSA uses modular exponentiation with a modulus formed from two secret prime factors. Knowing those factors allows the private exponent to be calculated.

• Elliptic-curve cryptography (ECC) relies on the difficulty of the elliptic curve discrete logarithm problem. It provides comparable security to RSA with smaller keys: a suitably chosen 256-bit ECC key and a 3072-bit RSA modulus each provide about 128 bits of security against non-quantum attacks.

• Diffie-Hellman provides key agreement, letting two parties calculate the same shared secret without transmitting it. It does not encrypt their messages. Recovering a participant’s secret exponent from its public value is a discrete logarithm problem. The exchange requires a separate way to authenticate the participants.

Public-key operations cost much more than symmetric encryption, so systems use them to establish keys and sign messages. Symmetric ciphers handle bulk data. Secure RSA encryption expands each plaintext block to a ciphertext block the size of its modulus. Common symmetric modes add only a small, bounded overhead per message.

The textbook version of RSA has separate security weaknesses. Its deterministic encryption lets attackers test plaintext guesses, and its mathematical structure permits predictable changes to ciphertext. Later enhancements added randomized encoding to address these attacks.

Digital Signatures

A digital signature is produced from a message and a private signing key. Anyone with the corresponding public key can verify it without gaining the ability to create signatures. Signatures provide three interfaces:

• public, private = generate_keys(): create a private signing key and a corresponding verification key.

• signature = sign(digest, private): sign the digest of a message with the signing key.

• true/false = verify(digest, signature, public): check the signature against the digest of the message you have, using the public key.

These interfaces are a conceptual description. A library may accept the message itself and compute the digest internally.

Hashing allows signature algorithms to process long messages efficiently, since the algorithm signs or verifies the digest rather than the message. A signature can also verify for another message with that digest, which is why collision resistance is important: it prevents an attacker from choosing two such messages in advance, obtaining a signature on one, and substituting the other.

For RSA, signing can be pictured as “encrypting” a value prepared from the message’s digest with the private key. The verifier “decrypts” the signature with the public key and checks the result against the message. RSA signatures use different encoding rules from RSA encryption, and this mental model does not apply to all signature algorithms. Other schemes verify a mathematical relationship among the message, signature, and public key without any corresponding encryption operation.

A signature supports non-repudiation because a recipient holding only the public key cannot produce it. Attribution still depends on how the private key was protected and whose key it is. A signature cannot identify who used a stolen key or establish that a message is true or software is safe.

Certificates and Trust in a Public Key

A public key can be obtained through an already trusted channel, but such channels often do not exist (for example, when accessing a website).

A certificate authority (CA) issues a digital certificate, a signed data structure that binds a public key to an identity. It is a trusted third party: an organization trusted to do the appropriate identity verification before issuing a certificate. For a website certificate, domain validation establishes control of the domain name, not that the website is honest or safe. A few of the important fields in a certificate are:

• Subject: the name (organization name, domain name, personal name)

• Public key: the subject’s public key

• Validity period: earliest and latest times the certificate should be used

• CA: the name of the organization that signed this data and vouches that the public key belongs to this subject (shown as the issuer in a certificate)

• CA signature: the signature of the CA (created with the CA’s private key)

A certificate chain links a certificate through the CAs that signed it to an already accepted trust anchor, usually a root certificate in a trust store. Each certificate’s signature is checked using the public key of the CA that signed it. Root certificates are commonly self-signed, but their self-signatures do not establish trust. That trust comes from an independent decision to accept the root.

Certificate validation also checks the validity period, requested domain name, authority of intermediate CAs, and applicable revocation requirements. The server must demonstrate possession of the matching private key, since anyone can copy a public certificate.

Certificates expire, but they may have to be revoked before then if the subject’s private key has been leaked. Revocation is hard to do well: a client has to learn about a revocation before it accepts the certificate, and every way of delivering that information is either stale, slow, or something an attacker can block.

Shorter certificate lifetimes limit how long a compromised certificate can remain usable, even when a client misses its revocation. Browser and CA rules are reducing the maximum lifetime of publicly trusted website certificates on a published schedule. Shorter lifetimes reduce exposure but do not replace revocation.

Signed Software and the Supply Chain

Code signing uses digital signatures to authenticate software and detect changes to its signed content. Verification may be performed by an operating system, installer, or package manager, according to the platform’s policy. The verifier also establishes trust in the signing key, often through a certificate chain.

Secure boot checks boot components before they execute, starting from a key protected by firmware or hardware and continuing through later startup stages.

A valid signature shows that the signed bytes have not changed and were authenticated with the corresponding private key. It does not prove that the software is safe or that the publisher reviewed the exact code being signed. A stolen key can also produce valid signatures.

A software supply chain attack can reach a signed release through several routes:

1. An attacker steals a signing key or obtains a fraudulent certificate. Key theft can leave the cryptographic algorithm unbroken. A fraudulent certificate can result from a broken hash or a compromised CA.

2. An attacker compromises the build system and causes the publisher’s legitimate signing process to authenticate malicious output.

3. An attacker alters a dependency that becomes part of the finished software. The publisher can then sign the affected release without any failure of the signature algorithm.

Quantum Computing Attacks

A sufficiently capable quantum computer could solve the factoring and discrete logarithm problems used by RSA, ECC, and Diffie-Hellman. Increasing their key sizes is not a practical long-term defense.

A generic quantum search can reduce an ideal search through \(2^n\) possibilities to roughly \(2^{n/2}\) steps. This applies to symmetric key searches and hash preimage searches. Larger keys and digests can easily compensate for that speedup. A 256-bit symmetric algorithm will provide 128 bits of security if a quantum computer is eventually built that can do such searches.

Harvest now, decrypt later (HNDL) describes recording encrypted traffic for decryption after a capable quantum computer becomes available. Data that must remain confidential for many years needs protection before that happens. Signatures also need a migration plan so long-lived devices can continue rejecting forged software updates.

Post-quantum cryptography uses constructions intended to resist both classical and quantum attacks. Standards exist for key establishment and digital signatures, including a signature scheme built from hash functions.

Protocols can use hybrid key establishment, combining a classical method with a post-quantum method and deriving a key from both results. With a properly designed combination, the shared secret remains protected if at least one method resists the attack.

What You Don’t Need to Study

The following are not required for the exam:

• Names of historical figures. Understand that scientists used anagrams to commit to discoveries before revealing them, but the method provided weak hiding and weak binding.

• Telegraph codebooks and the calculations behind CRCs, parity, check digits, and other error-detection codes. Distinguish accidental corruption from deliberate changes by an attacker who can recompute or preserve a check value.

• Incident names, malware names, and the organizations involved. Understand the attack patterns they illustrate, including key theft, certificate forgery, build compromise, and malicious dependencies.

• Individual hash-function names, beyond recognizing SHA-2 and SHA-3 as current families. Some older 128-bit and 160-bit hashes have design weaknesses that allow collision attacks faster than the generic birthday search.

• Arithmetic of any kind, including RSA key generation, Diffie-Hellman calculations, elliptic curve equations, and the calculations in the appendix to the notes. Focus on what each algorithm accomplishes and the assumptions its security depends on. The relationship between digest length and collision resistance is still required.

• HMAC padding and the values XORed with the key for the inner and outer digests.

• Names of standards organizations, the companies maintaining particular trust stores, and the names of quantum and post-quantum algorithms, including Shor’s and Grover’s.

• Hash compression internals and detailed certificate formats. Understand the roles of the main certificate fields (subject, public key, CA, and CA signature), along with the validation checks described above.

• Certificate Transparency and key fingerprints.

• The mechanisms for delivering revocation information (published lists, live status queries, status delivered in advance). Know why revocation is needed and why it is hard to do well.

• Names of particular signature schemes. Recognize RSA and elliptic-curve approaches, and know that signatures can also be built from hash functions. Know which key signs and which key verifies.

• The construction of hash-based one-time signatures.

• Patent and export control history.

• Key derivation functions. Know that RSA keys are built from the product of two primes and that the security of Diffie-Hellman rests on the discrete logarithm problem.

• Names of particular factoring algorithms and of specific code signing systems. Know what code signing accomplishes.

• Supply chain defenses, including reproducible builds, provenance records, software bills of materials, and release logs. Know the three routes by which an attack reaches a signed release.

• Exact key-size comparisons, such as a 256-bit elliptic curve key against a 3072-bit RSA modulus. Understand why different algorithms need different key lengths for comparable security.

Week 4: Authentication and Secure Communication

Cryptographic primitives protect individual messages. Protocols decide which messages to accept, from whom, and when. Protocols can fail even when every cryptographic operation works correctly, so focus on what each protocol proves, to whom, and what it leaves open. For authenticating people, focus on how each method fails and which defense matches which attack.

Security Protocols and the Adversary

A security protocol is a sequence of messages exchanged to achieve a goal, such as proving an identity or agreeing on a key. Protocols are analyzed against an adversary that controls the network. It can read, record, delete, delay, reorder, replay, and inject messages, start protocol runs with any party, and take part as a legitimate user with its own keys. It cannot break the cryptography.

An adversary in the middle (AiTM), also called a man in the middle (MITM), relays traffic between two parties who each believe they are talking directly to the other.

Key Establishment

Key establishment gets a shared secret key to the parties that need it, and only those parties. Pairwise keys grow as \(n(n-1)/2\), and they do not help two parties who have never met. Know the four approaches:

• A pre-shared key is distributed out of band. It works for small groups and is hard to change.

• A trusted third party shares a long-term key with every participant and issues session keys to pairs.

• Public key transport has one party generate a secret and encrypt it with the other’s public key.

• Diffie-Hellman key agreement lets two parties compute a shared secret from public values. It must be authenticated to resist an active attacker.

Replay and Freshness

A valid MAC shows that someone holding the shared key produced the message, and a valid signature shows that the private-key holder did. Neither shows when the message was produced or whether it was already accepted. A replay attack reuses a valid message outside its original context.

A message is fresh if the receiver has evidence that it belongs to the current exchange or an acceptable recent period. Know the three mechanisms and their costs:

• A nonce is a value used once. The party that wants assurance picks an unpredictable nonce and accepts only a reply that includes it under a MAC or signature. A nonce protects only the party that chose it.

• A timestamp avoids an extra round trip but requires clocks that agree within a tolerance. A replay inside that window succeeds unless the receiver remembers recent messages.

• A sequence number requires both sides to keep state and agree on how to handle gaps and restarts.

A freshness nonce ties a response to a current request. It is different from an AES-GCM nonce, which must never repeat under the same key, and from the per-signature value in ECDSA (the elliptic-curve signature algorithm), which must never repeat and must also be kept secret.

Challenge and Response

In challenge-response authentication, one party sends a fresh nonce, and the other returns a value only a key holder could compute, such as an HMAC of the nonce. The key never crosses the network, and a recorded response will not answer a new challenge. In one-way authentication, one party authenticates the other. In mutual authentication, both do.

A reflection attack works when both directions use the same key and computation. The attacker sends the challenger’s own nonce back in a second session and uses the answer in the first. The fix is to make the two directions distinguishable, by including the responder’s identity or using a different key in each direction.

Authenticating at the start does not protect later messages. If they are unprotected, an attacker can take over after authentication, which is session hijacking. An authenticated key exchange establishes shared keys and authenticates one or both participants, and those keys can then protect the messages that follow.

Key Distribution with a Trusted Third Party

A key distribution center (KDC) is a trusted third party. It shares a long-term key with each participant, which reduces the number of long-term keys from about \(n^2/2\) to \(n\). Every participant trusts the KDC to keep those keys secret and to give each session key only to the parties it was created for. Because the KDC knows every key, it can read any session it sets up and impersonate any participant, so an attacker who compromises it compromises everyone. A ticket is an encrypted credential that one party forwards to another and cannot read or change.

In each of these protocols, Alice wants to communicate with Bob, and Trent is the trusted third party that shares a long-term key with each of them and issues their session key. Understand how this family of protocols developed:

1. A basic protocol. The server sends Alice a session key and a ticket for Bob. Nothing establishes freshness, so a recorded ticket can be replayed to Bob indefinitely.

2. Needham-Schroeder (1978) adds Alice’s nonce, which shows Alice that the server’s reply is fresh, and a handshake that shows Bob that someone holding the session key is responding now.

3. The Denning-Sacco attack (1981): an adversary who recovers an old session key replays the old ticket to Bob and answers his handshake. Neither nonce tells Bob that the key itself is new.

4. The Denning-Sacco fix puts a timestamp inside the ticket, so Bob can reject old tickets himself, at the cost of synchronized clocks.

The general lesson is that evidence of freshness and of key possession has to be bound to the intended participant. Alice’s nonce does not protect Bob, and proof that someone holds a key does not show that it is the intended party.

Kerberos

Kerberos applies these ideas to an organization’s network and is the default authentication protocol for Windows domains. Understand how the key distribution center is split into two distinct roles:

• The authentication server (AS) verifies the user at login, using a key derived from the password, and issues a ticket-granting ticket (TGT).

• The ticket-granting server (TGS) accepts the TGT and issues a service ticket for each service. The password is not needed again, which provides single sign-on.

A ticket can be copied, so by itself it does not prove who is presenting it. An authenticator, the client’s name and the current time encrypted under the ticket’s session key, proves that the client holds that key. Services reject authenticators outside a tolerance window and remember recent ones, so replays fail.

The KDC is the center of trust. It must be available to issue tickets, and it holds every user’s and service’s long-term key, so compromising it compromises the whole system. Tickets encrypted under keys derived from human-chosen passwords can be guessed offline, so service accounts need long random passwords.

Public Key Authentication and Forward Secrecy

A signature on a fresh nonce shows that the signer’s private key was used in this exchange, and the verifier stores only a public key. A signature on a nonce alone can still be relayed, so a complete protocol binds it to the intended parties.

In public key transport, the client generates a random secret, encrypts it with the server’s public key, and sends it, and both sides derive session keys from it. TLS through version 1.2 offered this with RSA. Anyone who records the traffic and later obtains the server’s private key can decrypt every recorded session that used that key for key transport.

Diffie-Hellman does not authenticate anyone. An adversary in the middle runs one exchange with each side and shares a key with both. The fix is to sign the exchange with a long-term key that a certificate binds to an identity. In signed Diffie-Hellman, the long-term key only signs.

A hybrid cryptosystem uses public-key cryptography to authenticate the parties and establish a key, then protects the data with symmetric authenticated encryption, because public-key operations are slow.

Know the three key lifetimes:

• A long-term key authenticates a party across many connections.

• An ephemeral key, such as a fresh Diffie-Hellman private value, is used only to compute the shared secret and is then erased.

• A session key is derived from the shared secret and protects one connection.

Forward secrecy means that compromising a long-term key does not expose sessions recorded earlier. Ephemeral Diffie-Hellman provides it, because the values that produced each session key no longer exist. RSA key transport and Diffie-Hellman with a reused private value do not.

TLS

Transport Layer Security (TLS) protects HTTPS and many other connections. A TLS 1.3 connection runs in two phases: a handshake that sets up keys and authenticates the server, and then protected data transfer.

Phase 1: the handshake. Know what each part contributes:

• The client proposes TLS versions and algorithms, and the server chooses among them.

• Ephemeral Diffie-Hellman values from both sides produce a fresh shared secret with forward secrecy.

• The certificate chain binds the server’s public key to its domain name.

• The server’s signature over the transcript hash, a hash of the handshake so far, proves it holds the private key for this connection.

• Each side sends an HMAC over the transcript, confirming that both derived the same keys and saw the same messages.

Signing the transcript ties the server’s identity to this connection. An adversary who substitutes its own Diffie-Hellman value, or edits the list of versions and algorithms in a downgrade attack, changes the transcript, so the signature fails. TLS 1.3 removed RSA key transport and Diffie-Hellman with reused private values, so certificate-based handshakes always provide forward secrecy.

Phase 2: data transfer. TLS divides the data stream in each direction into chunks called records and protects each one with authenticated encryption (AEAD) under keys derived from the handshake. Each record’s protection includes its sequence number, which prevents an attacker from replaying records or changing their order without detection. The application still reads and writes an ordinary stream of bytes.

A client reconnecting to a server can send data in its first message, before the server replies. That early data can be replayed and lacks forward secrecy, so applications should accept it only when replaying it is harmless. TLS on the web authenticates only the server. Mutual TLS (mTLS) adds a client certificate.

Authenticating People

Identification is claiming an identity. Authentication verifies the claim. Authorization decides what the authenticated party may do.

The three authentication factors are something you know (a password), something you have (a phone or security key), and something you are (a fingerprint or face). Multi-factor authentication (MFA) requires factors from different categories.

Passwords and Second Factors

PAP sends the password to the server. A web login does the same inside TLS, so the password is protected in transit, but the server still receives it. CHAP returns a hash of the password and a server challenge, so the password never crosses the network, but the server must store the password in usable form.

For logins that send the password, as PAP and web logins do, the server should store salted password hashes, not passwords. A salt is a random value stored with each hash. It makes identical passwords hash differently and makes precomputed tables useless, but it does not slow down guesses against one account. A password hashing function, such as bcrypt, scrypt, or Argon2, is deliberately expensive, with a cost that can be raised over time.

A one-time password (OTP) is accepted once. Most are an HMAC, under a key shared by the device and the server, of a changing value: a counter for an HMAC-based one-time password (HOTP), or the current 30-second interval for a time-based one-time password (TOTP), which is what authenticator apps compute. An older approach, a hash chain, gives each login the previous value in a chain of hashes.

Be able to match each attack to its defenses:

Current NIST guidance favors length over complexity: long minimum lengths, no composition rules, no forced periodic changes, and checking new passwords against a blocklist.

Passkeys

A passkey is a public-key credential bound to one site. At registration, the device creates a key pair and the site stores the public key. At login, the site sends a fresh challenge. Before the device will use the private key to sign it, the user must unlock the key locally, with a fingerprint or face scan on devices that have a sensor, or with a device PIN. The check happens on the device, so neither the biometric nor the PIN is sent to the site.

Passkeys resist phishing because the browser, not the user, supplies the page’s origin. A passkey is bound to its site’s domain, so a lookalike site cannot request it, and the signed response covers the origin, so a relayed challenge fails. Theft of the site’s passkey records exposes public keys, not private keys.

Synced passkeys are copied to a user’s approved devices through a provider such as iCloud Keychain or Google Password Manager, so the private key leaves the device that created it. The provider encrypts it end to end, but the passkey is then only as safe as the provider’s account and recovery controls. Device-bound passkeys, such as those on a hardware security key, never leave one device. The remaining risks are weaker account recovery paths and malware or stolen session cookies after login.

Biometric Authentication

Biometric authentication verifies identity from physical or behavioral characteristics. Matching is approximate. The system compares a new sample with a stored template and accepts it if they are within a threshold. A fingerprint template, for example, records the positions of minutiae, distinctive points in the ridge pattern.

Know the error rates and how the threshold trades them off:

• The false accept rate (FAR) is the probability of accepting an impostor.

• The false reject rate (FRR) is the probability of rejecting the legitimate user.

• A stricter threshold lowers the FAR and raises the FRR. A receiver operating characteristic (ROC) curve shows every combination of the two that a system can reach. For a given system tested under given conditions, the threshold only selects a point on the curve. A better sensor, matcher, enrollment, or capture conditions can move the curve itself. A deployment chooses an operating point based on what it protects.

Verification compares a sample with one claimed identity’s template. Identification in the biometric sense, a different use of the word from claiming an identity, searches every template to find who the person is. Each additional comparison is another chance for a false match.

A presentation attack fools the sensor with a substitute, such as a photograph or molded finger, and liveness detection tries to confirm a live person. Templates cannot be protected with ordinary hashing, because a hash does not preserve similarity. They need other protection, such as encryption and access controls on a server, or secure hardware on a phone.

A stolen biometric cannot be revoked, the same traits are presented to every service, and samples lack a canonical form, so matching is approximate and searching many templates is expensive. Biometrics work best as a local check that unlocks a key on the device, as with passkeys.

What You Don’t Need to Study

The following are not required for the exam:

• Incidents, dates, figures, organizations, and people’s names. Understand the failures and defenses the incidents illustrate. Protocol and attack names used in this guide, such as Needham-Schroeder and Denning-Sacco, are still required.

• Protocol notation, exact message contents, Otway-Rees, the sidebar on Needham-Schroeder public-key authentication, and anything in the appendix.

• TLS message order, message names, and version history.

• Password-hashing parameters, benchmark numbers, PBKDF2, and the specific NIST requirements.

• S/Key, and how hash-chain one-time passwords are computed and verified.

• The FIDO2 and WebAuthn standards, and how providers synchronize passkeys. Understand how a passkey is bound to a site, how the user unlocks it on the device, and how synced and device-bound passkeys differ.

• Hybrid post-quantum key establishment, which was covered with integrity.

• Kerberos operational details and the name Kerberoasting.

• Biometric enrollment and feature-extraction steps, the names of specific minutiae and ridge patterns, and the comparison of irises and fingerprints.

• Cancelable templates and how liveness detection works. Know what liveness detection is for.

• Equal error rate (EER), coercion, and differences in biometric accuracy across populations.

Focus your review on these:

• What each protocol proves, to whom, and what it leaves open.

• Which freshness mechanism a protocol relies on, and its cost.

• How the adversary in the middle is stopped in Diffie-Hellman, TLS, and passkeys.

• Matching password and second-factor attacks to their defenses.

• Biometric error trade-offs, and why a biometric cannot be revoked.