ITIS 6200 / 8200: Principles of Information Security and Privacy

Weekly Paper Reading Schedule

This is the reading list for the semester. It mirrors the Canvas page. The full policy for how discussions are run is on the Policies page.

How the reading works. You read one required paper each week — about 17 pages on average. The group leading that week reads both papers, and presenting the contrast between them is part of their job. Three weeks (8, 10 and 15) require both papers of everyone — they are marked BOTH REQUIRED below — because in those weeks the comparison is the lesson. Groups claim a week through Canvas by 11:59pm Friday of week 1; the papers for each week are already fixed, so you are choosing a date and a topic, not bidding on a paper.

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. The full statement of how discussions work is on the Paper Discussions page.

You do not need a security background. Every required paper below lists exactly what you need to know first, and every one of those things is either taught earlier in this course or is general computer-science knowledge. Nothing required depends on a later lecture. If a reading assumes something you have not seen, that is a problem with the schedule and not with you — say so, and it will be fixed.

Reading load at a glance

Wk	Topic	Required of everyone	Pages
1	Introduction	Saltzer & Schroeder, Section I led in class	8
2	One-time Pad & Block Cipher	Mason et al. (two-time pad)	10
3	Cryptographic Hashes	Leurent & Peyrin (SHA-1)	18
4	MAC & Authenticated Encryption	Vaudenay, Sections 1–4, 6–7 lightest	7
5	PRNG & Diffie-Hellman	Heninger et al. (Ps and Qs)	16
6	Public-Key & Certificates	Rivest, Shamir & Adleman	15
7	Mid-term exam	—	0
8	Access Control	Sandhu + Reardon BOTH	30
9	Web & Cookies	Singh et al. (browser access control)	16
10	CSRF, XSS, SQL Injection	Barth + Steffens BOTH	27
11	Network, ARP, TCP	Bellovin	17
12	Firewall & Intrusion Detection	Ptacek & Newsham, Sections 1–4	13
13	Memory Layout, Stack, Heap	Aleph One single	25
14	Memory Vulnerabilities	Shacham, Sections 1–3	12
15	Mitigation	Abadi + Carlini BOTH	29
16	Project presentations	—	0

If your group is leading

You read both papers that week, and presenting the contrast between them is part of your job — most of the room will have read only one. The third discussion question listed for each week below is always a bridge question of exactly that kind; use it or write your own.

The five-part structure your discussion must follow, the time budget, and the grading rubric are all on the Paper Discussions page. Read that page once, at the start of term; use this one every week.

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 into the discussion.

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. Bridge: 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
One-time Pad & Block Cipher — 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. Bridge: 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 Cipher & Cryptographic Hashes — 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. Bridge: 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 4 · Tue 8 Sep
MAC & Authenticated Encryption — 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, XOR, and what a MAC is — all from Weeks 3–4.

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 11.
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. Bridge: WinZip encrypted its data and checksummed it. Name precisely what a checksum fails to provide that a MAC provides.

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. Bridge: Logjam works because everyone reuses the same parameters. Standardization is normally good practice — when does it become a liability?

Week 6 · Tue 22 Sep
Public-Key Encryption, Digital Signatures & Certificates — 15 pp

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.

RecommendedThree 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 11: 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 11.

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. Bridge: 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 — 30 ppBOTH REQUIRED

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.

Required50 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.

Why both this week: 30 pages, but both are easy reads, and the contrast is the concept. A clean model versus a leaking enforcement boundary is the entire lesson of access control.

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 9 · Tue 13 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. Bridge: 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 10 · Tue 20 Oct
CSRF, XSS, SQL Injection — 27 ppBOTH REQUIRED · 2 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 9.

RequiredDon'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 9.

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.

Why both this week: the week's real question is why SQL injection got solved and XSS did not. That comparison needs all three attack classes in the room at once.

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 11 · Tue 27 Oct
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. Bridge: Cao et al. exploit a rate limiter added for robustness. Where else in this course has shared global state created a side channel?

Week 12 · Tue 3 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 11.

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. Bridge: 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 13 · Tue 10 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.

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 13–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 14 · Tue 17 Nov
Memory Vulnerabilities — 12 pp

RequiredThe 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
Non-executable memory does not stop exploitation, because the attacker reuses the code already there. Nobody needs to verify the Turing-completeness argument.
Background you need: Stack layout from Week 13 and x86 assembly. The most background-dependent reading of the term.

RecommendedSpectre Attacks: Exploiting Speculative ExecutionMODERATE
Kocher et al. · arXiv preprint, 2018 · 16 pp (later published at IEEE S&P 2019)
Stretches “memory vulnerability” from software bugs to hardware optimization: memory-safe code leaking memory anyway.
Background you need: Caches and pipelining from a computer-architecture course.

Discussion questions

1. Return-oriented programming defeats non-executable memory by reusing existing code. Is there a general pattern in how mitigations get bypassed, or is each case idiosyncratic?
2. Shacham's construction is Turing-complete. Does that mean control-flow hijacking is unfixable in principle, or only unfixable by these means?
3. Bridge: Spectre is a hardware design flaw with software consequences. Who should pay to fix it — and what does your answer imply about the performance cost users bear?

Week 15 · Tue 24 Nov
Memory Vulnerabilities and Mitigation — 29 ppBOTH REQUIRED · 2 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 from Week 14, and what a control-flow graph is.

RequiredControl-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 13–14.

Why both this week: this is the only genuine attack-versus-defense rebuttal pair in the course, and the debate collapses if half the room has read only one side.

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. Week 7 is the mid-term and Week 16 is project presentations; neither has a reading.