ITIS 6200 / 8200: Principles of Information Security and Privacy

Weekly Paper Reading Schedule

This is the reading list for the semester. How the discussions are run and graded is on the Policies page.

Discussion slots are assigned by a seeded, publicly verifiable draw — see How the slot draws work at the bottom of this page.

How the reading works. You read one required paper each week — about 15 pages on average. On two-group weeks there is also a companion paper: the second leading group covers it in depth, and everyone else skims its introduction and conclusion (~10 minutes) so the whole room can join the discussion. Form your discussion/project group by the end of week 1; groups then claim a slot through Canvas by 11:59pm Friday of week 2 (the Week 2 discussion is led by a volunteer group, selected by seeded lottery — see how the draws work).

Why we read papers in this course. To understand the concepts from lecture more deeply — not to reproduce the research. You are not expected to follow every proof. Where a reading is excerpted, read only the sections listed. How discussions are run is on the Policies page.

You do not need a security background. Every required paper lists exactly what you need to know first, and it is either taught earlier in this course or is general computer-science knowledge. Nothing required depends on a later lecture.

Reading load at a glance

Wk	Topic	Required of everyone	Pages
1	Introduction to Security & Cryptography	Saltzer & Schroeder, Section I led in class	8
2	Symmetric-Key Encryption & One-Time Pad	Mason et al. (two-time pad)	10
3	Block Ciphers & Operating Modes	Vaudenay, Sections 1–4, 6–7 lightest	7
4	Cryptographic Hashes, MACs & Authenticated Encryption	Leurent & Peyrin (SHA-1)	18
5	PRNG & Diffie-Hellman Exchange	Heninger et al. (Ps and Qs)	16
6	Public-Key Encryption & Digital Signatures & Certificates	Rivest, Shamir & Adleman 2 GROUPS + companion (2nd group): Three Lessons from Threema: Analysis of a Secure Messenger — skim intro+conclusion; Group B covers it	15
7	MID-TERM EXAM (Covers lectures on Cryptography)	—	0
8	Access Control	Sandhu et al. (RBAC) 2 GROUPS + companion (2nd group): Reardon et al. — skim intro+conclusion; Group B covers it	10
9	Fall Break (Student Recess) – No class	—	0
10	Intro to Web and Cookies	Singh et al. (browser access control)	16
11	CSRF, XSS, SQL injection	Barth et al. (CSRF) 2 GROUPS + companion (2nd group): Steffens et al. — skim intro+conclusion; Group B covers it	12
12	Intro to Network, ARP, TCP	Bellovin	17
13	Firewall, Intrusion Detection	Ptacek & Newsham, Sections 1–4	13
14	Intro to Memory layout, Stack, Heap	Aleph One single	25
15	Memory Vulnerabilities & Mitigation	Abadi et al. (CFI) 2 GROUPS + companion (2nd group): Carlini et al. — skim intro+conclusion; Group B covers it	13
16	Project presentation	—	0
17	Final Exam (8am-10:30am)	—	0

If your group is leading

What you owe depends on your week. Single-paper weeks (one leading group): read the required paper deeply and lead ~25–30 min — any Recommended paper listed that week is optional for you, like for everyone else. Two-group weeks (marked “2 GROUPS”: weeks 6, 8, 11, 15): both groups read both papers, and presenting the contrast between them is part of the job — Group A leads the required paper (~25 min), Group B leads the companion (~15–20 min: key ideas + contrast). The five-part structure and rubric are on the Policies page.

If your group is non-leading

Every non-leading group posts one discussion question (or one criticism/observation) by 9:30 AM on the day of class. The leading group reviews these before class and incorporates some of them.

The readings

Week 1 · Tue 18 Aug
Introduction to Security & Cryptography — 8 pp, led in class

RequiredThe Protection of Information in Computer SystemsEASY
Saltzer & Schroeder · Proceedings of the IEEE, 1975 · Section I only, ~8 pp of 31
The eight design principles — least privilege, fail-safe defaults, economy of mechanism, open design. Still the vocabulary every security argument is conducted in. Read Section I only.
Background you need: None. This is the one reading in the course with no prerequisites at all.

RecommendedSoK: Science, Security, and the Elusive Goal of Security as a Scientific PursuitMODERATE
Herley & van Oorschot · IEEE S&P, 2017 · 22 pp
Argues much security work fails basic scientific standards. It licenses you to be skeptical of every paper assigned after it.
Background you need: General research literacy. No technical prerequisites.

Discussion questions

1. Pick one system you use daily. Which of the eight principles does it violate, and was that a mistake or a deliberate trade?
2. The principles have never been meaningfully revised in fifty years. Is that because they are right, or because nobody has tried?
3. Herley & van Oorschot ask what a falsifiable security claim would look like. Take one Saltzer principle — can it be tested, or is it only a heuristic?

Week 2 · Tue 25 Aug
Symmetric-Key Encryption & One-Time Pad — 10 pp

RequiredA Natural Language Approach to Automated Cryptanalysis of Two-Time PadsMODERATE
Mason, Watkins, Muth, Eisner & Stubblefield · ACM CCS, 2006 · 10 pp
What actually happens when a one-time pad gets used twice: the redundancy of English is enough to pull both plaintexts back out, automatically. The concrete counterweight to the perfect-secrecy proof.
Background you need: XOR and the definition of a one-time pad, both from this week's lecture, plus basic probability. No networking, no protocols.

RecommendedCommunication Theory of Secrecy SystemsHARD
Claude Shannon · Bell System Technical Journal, 1949 · Sections 1–10, ~15 pp of 60
Where perfect secrecy is defined and the one-time pad proved optimal. Genuinely hard; if you read it, the goal is to see why the key must be as long as the message.
Background you need: Comfort with probability and formal definitions.

Discussion questions

1. The one-time pad is provably unbreakable, and this paper breaks it. Precisely which assumption of the proof failed?
2. The attack works because English is redundant. What would you have to encrypt for a two-time pad to stay safe — and is that ever realistic?
3. Shannon proves the one-time pad is perfectly secret. Given a proof that strong, why does essentially nobody use it? Name the engineering property that kills it.

Week 3 · Tue 1 Sep
Block Ciphers & Operating Modes — 7 pp, lightest week

RequiredSecurity Flaws Induced by CBC PaddingMODERATE
Serge Vaudenay · EUROCRYPT, 2002 · Sections 1–4 and 6–7, ~7 pp of 8
The padding-oracle attack, built from first principles. The cleanest possible demonstration of why encryption without integrity is not enough. Section 5 maps the attack onto specific protocols — skip it.
Background you need: CBC mode, padding, and XOR — all from this week's lecture. What a MAC is arrives next week; the one-sentence version you need is given in class.

RecommendedAttacking and Repairing the WinZip Encryption SchemeMODERATE
Tadayoshi Kohno · ACM CCS, 2004 · 10 pp
A concrete, entirely symmetric-crypto example of the same lesson: WinZip encrypted and checksummed, which is not the same as authenticating.
Background you need: AES-CTR, HMAC, and CRC checksums. No networking or public-key crypto.

ReferenceLucky Thirteen: Breaking the TLS and DTLS Record Protocols
AlFardan & Paterson · IEEE S&P, 2013 · 16 pp
Optional, and best read late in the term. This is Vaudenay's attack carried into TLS via microsecond timing — it will make much more sense after Week 12.
Background you need: Requires the TLS record protocol and network timing, neither of which is covered yet.

Discussion questions

1. The attacker learns one bit — whether padding was valid — and recovers the entire plaintext. How is that possible from one bit?
2. Encrypt-then-MAC, MAC-then-Encrypt, Encrypt-and-MAC. Which composition does this attack require, and would it survive under the others?
3. (Optional, from the recommended WinZip paper) WinZip encrypted its data and checksummed it. Name precisely what a checksum fails to provide that a MAC provides — the concept is answerable from lecture alone.

Week 4 · Tue 8 Sep
Cryptographic Hashes, MACs & Authenticated Encryption — 18 pp

RequiredSHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of TrustMODERATE
Leurent & Peyrin · USENIX Security, 2020 · 18 pp
A forged identity certificate for about $45K of GPU time. It turns collision resistance from a math property into a budget line.
Background you need: What a hash function is and what a collision is, both from this week's lecture. Skim the differential-path sections.

RecommendedHow to Break MD5 and Other Hash FunctionsHARD
Wang & Yu · EUROCRYPT, 2005 · 17 pp
The paper that ended MD5. Read it for the result and the differential-path idea. Nobody is expected to verify the differentials.
Background you need: Hash construction internals and comfort reading bit-level notation.

Discussion questions

1. Distinguish collision resistance from second-preimage resistance. For which real systems does a plain collision matter, and for which is it harmless?
2. The attack costs about $45K. How should a standards body use a number like that — what is the right safety margin, and in what units?
3. MD5 fell in 2005 and was still in production a decade later; SHA-1 repeated the pattern. Whose job is deprecation, and why is that job structurally so hard?

Week 5 · Tue 15 Sep
PRNG & Diffie-Hellman Exchange — 16 pp

RequiredMining Your Ps and Qs: Detection of Widespread Weak Keys in Network DevicesEASY
Heninger, Durumeric, Wustrow & Halderman · USENIX Security, 2012 · 16 pp
Scanned the entire internet and factored real devices' keys, because embedded systems generated them before they had any entropy. The best argument ever made for taking random-number generation seriously.
Background you need: Randomness and entropy from this week's lecture, plus one fact from Week 6 the instructor will state first: an RSA public key is the product of two large secret primes, so if two keys share a prime a GCD recovers both.

RecommendedImperfect Forward Secrecy: How Diffie-Hellman Fails in PracticeMODERATE
Adrian et al. · ACM CCS, 2015 · 13 pp (Logjam)
A handful of hardcoded primes protect most of the internet — precompute against one, break millions of connections.
Background you need: Diffie-Hellman from this week; the precomputation argument stands on its own.

Discussion questions

1. These devices ran correct, well-tested key-generation code. Where exactly did security get lost, and which layer of the stack owned that failure?
2. The work depends on scanning the entire internet. What ethical constraints should govern that kind of research, and did these authors meet them?
3. Two RSA keys generated independently on different devices turned out to share a prime factor, which let the authors factor both. What does that single observation prove about how those keys were generated — and why is it far more damning than finding one weak key?
4. (Optional, from the recommended Logjam paper) Logjam works because everyone reuses the same Diffie-Hellman parameters. Standardization is normally good practice — when does it become a liability?

Week 6 · Tue 22 Sep
Public-Key Encryption & Digital Signatures & Certificates — 15 pp2 GROUPS LEAD

RequiredA Method for Obtaining Digital Signatures and Public-Key CryptosystemsEASY
Rivest, Shamir & Adleman · CACM, 1978 · 15 pp (single-column reprint; the printed CACM version is 7)
Covers both halves of the week — encryption and signatures — in prose you can follow start to finish.
Background you need: Modular arithmetic and prime factorization. Entirely self-contained.

RecommendedLed by 2nd groupThree Lessons from Threema: Analysis of a Secure MessengerMODERATE
Paterson, Scarlata & Truong · USENIX Security, 2023 · 18 pp
Seven attacks on a shipping “secure” messenger, nearly all from misusing sound primitives rather than breaking them.
Background you need: Public-key encryption, signatures and key exchange.

ReferenceBamboozling Certificate Authorities with BGP
Birge-Lee, Sun, Edmundson, Rexford & Mittal · USENIX Security, 2018 · 16 pp
Optional now, much better after Week 12: hijack a route, pass domain validation, get a real certificate for a domain you do not own.
Background you need: Requires BGP and internet routing, which arrive in Week 12.

Discussion questions

1. RSA assumes you already know the recipient's true public key. Where does that assumption get discharged in practice, and what does it cost?
2. The paper is seven pages and launched a fifty-year industry. What made it so compact — and could a result like this be published that briefly today?
3. Threema used sound primitives and still failed seven ways. What does that say about where security effort should actually be concentrated?

Week 8 · Tue 6 Oct
Access Control — 10 pp2 GROUPS LEAD

RequiredRole-Based Access Control ModelsEASY
Sandhu, Coyne, Feinstein & Youman · IEEE Computer, 1996 · 10 pp
The RBAC reference model every enterprise identity system is still a variation on. Clean diagrams, no formal background required.
Background you need: None beyond this week's lecture.

RecommendedLed by 2nd group50 Ways to Leak Your Data: An Exploration of Apps' Circumvention of the Android Permissions SystemEASY
Reardon, Feal, Wijesekera, Elazari Bar On, Vallina-Rodriguez & Egelman · USENIX Security, 2019 · 20 pp
Real app-store apps systematically routing around a well-designed permission model via side and covert channels.
Background you need: Basic familiarity with how mobile apps request permissions.

Discussion questions

1. Sandhu's model assumes the reference monitor sees every access. Which circumvention techniques in Reardon et al. violate that — and is it a model failure or an implementation failure?
2. RBAC is thirty years old and still dominant. Is that because it is right, or because migration costs make anything else infeasible?
3. Reardon et al. found thousands of misbehaving apps at once and disclosed to Google. What obligations does a measurement paper carry at that scale?

Week 10 · Tue 20 Oct
Intro to Web and Cookies — 16 pp

RequiredOn the Incoherencies in Web Browser Access Control PoliciesMODERATE
Singh, Moshchuk, Wang & Lee · IEEE S&P, 2010 · 16 pp
Treats the browser as an access-control system — principals, resources, policies — and shows its own policies disagree with each other.
Background you need: The same-origin policy and cookies, both from this week's lecture. It also needs Week 8's access-control ideas and knowing what a URL and JavaScript are.

RecommendedSecuring Frame Communication in BrowsersMODERATE
Barth, Jackson & Mitchell · USENIX Security, 2008 · 14 pp
How frame navigation broke isolation between sites. This work directly shaped the HTML5 postMessage design.
Background you need: Assumes the same-origin policy is already understood — read it after the required paper.

Discussion questions

1. The browser has to isolate mutually distrusting sites in one process, with no installer and no administrator. Which of Week 8's access-control assumptions survive that setting?
2. The paper finds browser policies that contradict each other. Why would a policy end up incoherent over twenty years?
3. If the browser is an access-control system, what is the principal, what is the resource, and who is the reference monitor? Where does the analogy break?

Week 11 · Tue 27 Oct
CSRF, XSS, SQL injection — 12 pp2 GROUPS LEAD

RequiredRobust Defenses for Cross-Site Request ForgeryEASY
Barth, Jackson & Mitchell · ACM CCS, 2008 · 12 pp
Introduces login-CSRF and the Origin header. The reason every web framework ships CSRF tokens by default.
Background you need: Cookies and the same-origin policy from Week 10.

RecommendedLed by 2nd groupDon't Trust The Locals: Investigating the Prevalence of Persistent Client-Side Cross-Site Scripting in the WildMODERATE
Steffens, Rossow, Johns & Stock · NDSS, 2019 · 15 pp
Large-scale crawl showing XSS moved client-side into browser storage while defenses stayed server-side.
Background you need: JavaScript and the same-origin policy from Week 10.

RecommendedCookie Crumbles: Breaking and Fixing Web Session IntegrityHARD
Squarcina, Adão, Veronese & Maffei · USENIX Security, 2023 · 18 pp
Cookies still have no integrity guarantee: Secure, prefixes and SameSite all bypassable, with 12 CVEs.
Background you need: Session fixation and CSRF. Also assumes subdomain structure.

ReferenceA Classification of SQL-Injection Attacks and CountermeasuresEASY
Halfond, Viegas & Orso · ISSSE, 2006 · 13 pp
Skim only, for the taxonomy. There is no strong recent SQL injection paper at a top venue, because parameterized queries essentially solved the class.
Background you need: Basic SQL. Nothing else.

Discussion questions

1. SQL injection is largely solved by parameterized queries; XSS has no analogous single fix. What structural difference between the two explains that?
2. Steffens et al. find defenses sitting server-side while the vulnerability moved client-side. What other defenses in this course are guarding the wrong place?
3. CSRF defenses became framework defaults; content-security policies require per-site configuration and are widely misconfigured. What does that predict about which mitigations work at scale?

Week 12 · Tue 3 Nov
Intro to Network, ARP, TCP — 17 pp

RequiredSecurity Problems in the TCP/IP Protocol SuiteEASY
Steven M. Bellovin · ACM SIGCOMM CCR, 1989 · 17 pp
The origin document for sequence-number prediction, spoofing and routing attacks — written before most were exploited.
Background you need: TCP/IP basics from this week's lecture.

RecommendedOff-Path TCP Exploits: Global Rate Limit Considered DangerousMODERATE
Cao, Qian, Wang, Dao, Krishnamurthy & Marvel · USENIX Security, 2016 · 17 pp
A shared counter in Linux's TCP stack becomes a side channel enabling blind connection hijacking.
Background you need: TCP connection state and sequence numbers from this week.

Discussion questions

1. Bellovin described these attacks in 1989 and many persist. Which are fixed, which are not, and what distinguishes the two groups?
2. He published attacks before they were exploited. Was that responsible in 1989? Would it be today?
3. Cao et al. exploit a rate limiter added for robustness. Where else in this course has shared global state created a side channel?

Week 13 · Tue 10 Nov
Firewall, Intrusion Detection — 13 pp

RequiredInsertion, Evasion, and Denial of Service: Eluding Network Intrusion DetectionMODERATE
Ptacek & Newsham · Secure Networks Inc. technical report, 1998 · Sections 1–4 only, ~13 pp of 63
If the monitor's model of the endpoint differs at all from the endpoint, detection fails. Read Sections 1–4 only.
Background you need: IP fragmentation and TCP reassembly, both from Week 12.

RecommendedDos and Don'ts of Machine Learning in Computer SecurityEASY
Arp et al. · USENIX Security, 2022 · 20 pp
Sampling bias, spurious correlation, bad baselines — why ML detection papers report results that do not survive deployment. If your course project involves machine learning, read this one.
Background you need: Introductory machine learning. No security background needed.

Discussion questions

1. The core insight is that monitor and endpoint disagree about semantics. Does pervasive encryption make this better or worse for a modern detector?
2. Base-rate fallacy: at realistic attack rates, what false-positive rate does a detector need before its alerts are worth a human's attention?
3. Arp et al. find pervasive methodological flaws in published work. If you were reviewing for a top venue, what three checks would you make mandatory?

Week 14 · Tue 17 Nov
Intro to Memory layout, Stack, Heap — 25 pp, single paper

RequiredSmashing the Stack for Fun and ProfitEASY
Aleph One · Phrack 49, File 14, 1996 · ~25 pp
No paired reading this week. The best hands-on introduction to stack layout and buffer overflow ever written.
Background you need: Reading C, and willingness to look at x86 assembly. If you have not written C or seen assembly, work through the course primer before this week — the steepest background jump in the term.

RecommendedThe Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)HARD
Hovav Shacham · ACM CCS, 2007 · Sections 1–3 only, ~12 pp of 30
Where return-oriented programming comes from — the attack CFI was built to stop. Read Sections 1–3 if you want the full construction; the lecture covers the idea.
Background you need: Stack layout from this week's lecture and Aleph One reading, plus x86 assembly.

ReferenceSoK: Eternal War in Memory
Szekeres, Payer, Wei & Song · IEEE S&P, 2013 · 16 pp
Unit reference, not a weekly reading. Keep it open across Weeks 14–15.
Background you need: Best read alongside the unit rather than before it.

Discussion questions

1. Aleph One's exact technique fails on a default modern system. Which specific mitigations stop it — and does the underlying bug still exist in code today?
2. This was published as a magazine article for attackers, not as a peer-reviewed paper. Did that change what it accomplished?
3. C and C++ still run most critical infrastructure thirty years later. Is that a technical problem or an economic one?

Week 15 · Tue 24 Nov
Memory Vulnerabilities & Mitigation — 13 pp2 GROUPS LEAD

RequiredControl-Flow Integrity: Principles, Implementations, and ApplicationsMODERATE
Abadi, Budiu, Erlingsson & Ligatti · ACM CCS, 2005 · 13 pp
The foundational software mitigation for control-flow hijacking, now shipping in every major compiler.
Background you need: Return-oriented programming (covered in lecture this week; see the recommended Shacham paper), and what a control-flow graph is.

RecommendedLed by 2nd groupControl-Flow Bending: On the Effectiveness of Control-Flow IntegrityMODERATE
Carlini, Barresi, Payer, Wagner & Gross · USENIX Security, 2015 · 16 pp
Attacks that stay entirely inside the control-flow graph that CFI enforces. The two leading groups take one paper each and argue.
Background you need: The CFI paper above. Read them in order.

RecommendedCHERI: Hardware-Enabled C/C++ Memory Protection at ScaleEASY
Watson et al. · IEEE Security & Privacy magazine, 2024 · 12 pp
Change the hardware so the bug class cannot exist. A good optional read heading into the final.
Background you need: The memory-safety problem from Weeks 14–15.

Discussion questions

1. CFI restricts control flow to the control-flow graph; Control-Flow Bending attacks within it. Is a fully precise graph achievable — and if not, is CFI's ceiling a bug or a definition?
2. Compare three strategies: patch bugs, block exploitation, eliminate the bug class. Where should a fixed security budget go, and does your answer change for a startup versus a government?
3. CHERI needs new hardware and recompilation. Weigh a decade-scale transition against the cost of the bugs it prevents. Is it worth it?

Every link above is a free, open-access copy — no library login required. Weeks with no reading are the mid-term, project presentations, and the final.

How the slot draws work (and how to verify them)

All random draws in this course are seeded and deterministic: the seed ITIS6200/8200 was announced before sign-ups opened, the algorithms are public, and the same inputs always produce the same result. No draw depends on anything I can quietly change after the fact.

Week 2 (volunteer lottery). Volunteer group names are sorted alphabetically, shuffled once with the seed, and the first name in the shuffled order leads Week 2. The complete procedure, runnable on any machine with Python ≥ 3.2:

import random volunteers = sorted([...]) # the volunteer groups random.Random("ITIS6200/8200").shuffle(volunteers) print(volunteers[0]) # the Week 2 leader

Main draw (all remaining slots). Slots are assigned by rank-weighted maximum matching, solved with scipy.optimize.linear_sum_assignment — the standard public implementation of the Hungarian algorithm. Each group's three ranked choices cost 0, 1, and 2; every other slot costs 100. Because 100 outweighs any combination of ranks, the solver first maximizes the number of groups receiving a slot they asked for, and only then prefers first choices over second and third. If any arrangement exists in which every group gets one of its choices, this procedure finds it — unlike a pick-in-random-order draw, no group loses out to bad luck when a better arrangement was possible. Ties between equally good arrangements are broken by shuffling the group and slot order with the same seed before solving. Groups whose three choices are all impossible to grant, and groups that did not respond, receive slots from what remains in a second seeded pass (seed ITIS6200/8200|pass2).

Verifying. The exact script used for both draws is published as-is (ask me for run_draw.py). Submitted rankings are not posted publicly — if you would like to verify a draw end-to-end, come to office hours and I will run the script with you from the raw form export. Each group can also privately confirm that its own outcome is consistent with the ranking it submitted.