Syllabus — Fall 2026

601.445/601.645 Practical Cryptographic Systems Mondays & Wednesdays 3:00–4:15 pm · First class August 31 · Last class December 9

Classroom: Krieger 170. Slides and video recordings of lectures will be made available eventually, but not immediately after class.

Course communications: we will use Piazza for all course communications — announcements, Q&A, and assignment clarifications. Please sign up here at the start of the semester.

Both sections (undergraduate 601.445 and graduate 601.645) meet together and follow the same structure.

Course description

This is a course about cryptography as it is used in real systems: encryption, authentication, key exchange: classical and post-quantum (ML-KEM), secure protocols (TLS, Signal), side-channel attacks, multi-party computation, zero-knowledge proofs, anonymity systems, and cryptographic backdoors. The emphasis throughout is practical: you’ll implement cryptographic systems, attack them, and learn to recognize the implementation mistakes that cause real-world failures.

Prerequisites: Working programming ability in Python (see Programming assignments below), plus comfort with basic probability and algebra. Prior security coursework helps but is not required. Graduate students (601.645) complete the same assignments with additional depth expected on exams and written work.

How this course works in the age of AI

AI coding assistants can now complete traditional programming assignments end to end. Rather than pretend otherwise, this course is built around that fact:

AI tools are permitted and encouraged on all take-home work (programming assignments and written homework), with disclosure (see AI policy below).
Portions of the code still need to be written and understood by you: assignments will be very specific about this. Let the AI agents do the dumb glue work.
Your grade primarily reflects what you can demonstrate in person: written exams and interactive code-review sessions, where no tools are available.
Assignments are still essential — they are where the learning happens, and the in-person components directly examine your submitted code. Students who outsource an assignment without understanding it will discover that the assignment credit was the smallest part of what they lost.

Grading

Component	Weight	Notes
Written exams & quizzes (in person)	40%	In-class quizzes, best 4 of 6 (12%); Midterm (12%); Final (16%)
Interactive code-review labs	25%	Three rounds, one after each programming assignment
Programming assignments	15%	Three assignments; autograded, plus TA-graded analysis and written parts
Written homework	10%	Separate problem sets; dates announced during the semester
Reading engagement	5%	Details TBA in September
Participation	5%	In-class engagement

Written exams and in-class quizzes

Three kinds of in-person assessment, all on paper with no books or devices (the midterm and final allow one handwritten sheet, see below):

In-class quizzes (6 total; best 4 count, 3% each). Short (10–12 minute) quizzes at the start of class, every other Monday, on the dates marked in the Schedule, each covering the lectures and readings since the previous quiz. The two dropped quizzes are the makeup policy — there are no makeup quizzes, so save your drops for illness and travel.
Midterm exam (12%), Monday October 5. Covers all material through Sep 30. No books, no electronics. You may bring a single 8.5×11 sheet of paper, handwritten, both sides.
Final exam (16%) during the December examination period (date set by the registrar, TBA). Cumulative, weighted toward post-midterm material. No books, no electronics. You may bring a single 8.5×11 sheet of paper, handwritten, both sides.

Expect a substantial fraction of midterm and final questions to involve reading and evaluating code and protocols: explaining what a routine does, identifying the vulnerability in a fragment, or critiquing a proposed design (“an AI assistant produced this key-exchange implementation: what’s wrong with it?”).

Interactive code-review labs

After each programming assignment, you will sign up for a 15-minute individual session with course staff, scheduled outside class time. In the session you will:

walk through your own submission and explain how it works;
answer questions about the security-critical regions designated in the assignment handout (e.g., nonce and IV handling, padding, MAC verification, key derivation, randomness use, constant-time comparison);
make or explain a small live modification (“what would break if…?”), which may include finding bugs planted in a modified copy of your own code.

Sessions are graded with a standard rubric shared in advance. The skill being assessed, such as reviewing security-critical code you did not necessarily write yourself, is exactly the skill that modern cryptographic engineering demands.

Programming assignments

Three programming assignments, autograded for functionality. Assignments are written in Python. The autograder tests command-line and wire-protocol behavior, so other languages are technically possible, but you must ask the instructor for permission on Piazza before you start, and course staff must be able to review your code in whatever you choose. (Course reference materials and skeletons are provided in Python; using them is optional.) One rule connects assignments to the review labs: you must pass the autograder to sign up for the corresponding review lab, and no review means no review-lab credit. The review lab is graded separately (25% of the course grade, across the three rounds) and does not change your assignment score.

Reading engagement (TBA)

An optional structured reading platform with embedded practice questions is under consideration; details and the associated 5% credit mechanism will be announced in September. Honestly, I’m not sure if this is worth it, which is why it’s not final.

AI policy

Take-home work (programming assignments, written homework): AI assistants and coding agents are allowed and encouraged. Each submission must include a brief AI usage note: what tools you used, what you delegated, what you verified yourself, and one thing you learned from (or caught wrong in) the AI’s output. This note is not graded for how much you used AI (using none is fine, using a lot is fine) but omitting the note or misrepresenting your process is an academic integrity violation.
In-person work (exams, code-review labs): no tools, no devices, no AI.
You are responsible for every line you submit. “The agent wrote that part” is not an answer that will serve you well in a review session.
The course provides (optionally) a context bundle you can load into your own AI assistant, configured to tutor rather than solve. Details in September.

Policies

Late work: You have 120 late hours (5 days) across the semester for take-home work, tracked via Gradescope, no questions asked. After they are exhausted, late work receives zero credit. Late hours do not apply to exams or review-lab sign-ups. For genuinely exceptional circumstances, contact the instructor.
Collaboration: Except where explicitly noted, all submitted work must be completed individually. You may discuss ideas with classmates; you may not share code or solutions. (Your AI assistant is not a “collaborator” for the purposes of this rule [see AI policy] but another student’s AI transcript is.)
Academic integrity: governed by the JHU honor code and the CS Department integrity code — see the dedicated section below.
Accommodations: Students with documented disabilities should contact Student Disability Services and the instructor early in the semester; review-lab formats can be adapted.

Academic integrity and the JHU honor code

All work in this course is governed by the JHU undergraduate ethics code and the CS Department Academic Integrity Code. You are responsible for reading both. In-person assessments (the midterm, quizzes, and the final) carry the standard university pledge:

I agree to complete this exam without unauthorized assistance from any person, materials, or device.

The following are violations in this course, consistent with the CS integrity code: cheating on exams or quizzes; bringing unauthorized materials, devices, or AI tools to any in-person assessment; submitting another person’s work (or another person’s AI transcript) as your own; falsifying program output or results; altering graded work for regrade; and facilitating any of these for another student.

How this interacts with our AI policy. This course permits and encourages AI tools on take-home work, so ordinary AI use there is not a violation — that is the whole point of the two-lane design. What remains a violation is misrepresenting your process: omitting the required AI usage note, lying about what you did versus what a tool did, or claiming authorship you cannot support. The honor code’s core demand — be honest about whose work this is — is exactly what the AI usage note asks of you. When in doubt about whether a specific use is permitted, ask on Piazza before the deadline, not after.

Suspected violations are referred to the appropriate university ethics board. Penalties are determined through that process and can include failure of the assignment or the course.

Textbooks and readings

There is no required textbook to purchase. Readings will be drawn from:

Draft chapters of my book: the primary reading for the symmetric-cryptography portion of the course (symmetric encryption & authentication, hash functions, random number generation, with portions of the public-key chapter as available). Posted on the Schedule as each excerpt becomes ready; please do not redistribute drafts;
Boneh & Shoup, A Graduate Course in Applied Cryptography (free online) — supplementary reference for selected topics;
Ross Anderson, Security Engineering (free online) — supplementary;
Selected papers and incident postmortems, linked from the Schedule.

Lecture slides will be posted on the Schedule after each class.

This syllabus may be revised during the semester; the authoritative version is always the one on this page.

Authorship & AI usage note (in the same format this course requires of you): This syllabus was written by Matthew Green with Claude (Anthropic’s Fable 5 model, via Claude Code). Delegated to the AI: a literature review of post-LLM assessment research, drafting of this document and the course website, and the semester date arithmetic. Done by the human: the course design and every grading decision, plus review and editing of every section you just read. One thing we learned from the process: the research consistently shows that students won’t use a course-provided chatbot when better general-purpose ones exist — which is partly why this course’s AI integration looks the way it does.