nadim/appliedcryptography
SHA256
1
Fork 0
Code Wiki Activity

Migrate back to Git LFS

Browse source
This commit is contained in:
Nadim Kobeissi 2025-06-26 12:19:00 +02:00
parent 6b34b62aa2
commit 4b6498ede3
Signed by: nadim
SSH key fingerprint: SHA256:o0JJHYcP8LVBoARMU+JjVbzJxL3HxW2F+C0yu/5zPgc
237 changed files with 36953 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

11
.gitattributes vendored Normal file
View file

@ -0,0 +1,11 @@
*.pdf filter=lfs diff=lfs merge=lfs -text
*.woff2 filter=lfs diff=lfs merge=lfs -text
*.ttf filter=lfs diff=lfs merge=lfs -text
*.otf filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.webp filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.gif filter=lfs diff=lfs merge=lfs -text
*.svg filter=lfs diff=lfs merge=lfs -text
*.ico filter=lfs diff=lfs merge=lfs -text

33
.gitignore vendored Executable file
View file

@ -0,0 +1,33 @@
# macOS
.DS_Store
# LaTeX
*.aux
*.bcf
*.idx
*.log
*.out
*.bbl
*.blg
*.xml
*.toc
*.fls
*.fdb_latexmk
*.lot
*.lof
*.ind
*.ilg
*.xdv
__latex*
*synctex*
*.listing
*.fmt
*.nav
*.snm
*.vrb
# Compiled materials
website/slides/*.pdf
website/labs/*.pdf
website/problem-sets/*.pdf
website/syllabus.pdf

13
NOTES.md Normal file
View file

@ -0,0 +1,13 @@
# Random Notes for Me (Please Ignore)
- [ ] Every time I show a new security property in Part 1, I should link it to an attack. This means redoing all the Part 1 slides after a first pass where I integrate the Joy of Cryptography materials. Eg. I describe what uniform sampling is? OK, look what happened with [PuTTY](https://thehackernews.com/2024/04/widely-used-putty-ssh-client-found.html) when they didn't respect this! See? This stuff matters in the real world!
- [ ] An "escape hatch" into more informal proofs should be readily available in the event of running out of time, etc., but should not be too heavily relied upon.
- [ ] None of the material covers key management. [Alfred Menezes](https://www.youtube.com/watch?v=C9e023bTfes&list=PLA1qgQLL41SRn_23p8zD0vUpKM4qOgt_T&index=6) may come to the rescue.
- [ ] **Must** be up-front about exam-required materials. Tell students what's required for each exam first thing. That way, you remove anxiety, and allow them to explore the materials at their leisure.
- [ ] [This website](https://asecuritysite.com/range/age) is full of useful practical examples, here we have range proofs.
- [ ] Not enough attack labs.
- [ ] Might be fun to cover QUIC, HTTP/3, Passkeys...
- [ ] Session on side-channels?
- [ ] Integrate Verifpal as learning tool
- [ ] [Amazing teaching style](https://www.youtube.com/watch?v=fOGdb1CTu5c)
- [ ] [Excalidraw](https://excalidraw.com) might be useful.

23
README.md Normal file
View file

@ -0,0 +1,23 @@
<img src="website/res/img/aub_red.png" alt="AUB Logo" style="max-width: 200px">
# Applied Cryptography (CMPS 297AD/396AI)
This repository contains source code of the course materials for Applied Cryptography (CMPS 297AD/396AI) at the American University of Beirut.
If you are a student or someone trying to learn from this course's materials, there is no point in browsing this repository, since it only contains uncompiled sources. For a better experience, ignore this repository completely and access the materials through the course website: [appliedcryptography.page](https://appliedcryptography.page)
## Contents
- `assignments`: Course assignments and lab sessions.
- `misc`: LaTeX dependencies.
- `slides`: Course slides.
- `syllabus`: Course syllabus.
- `website`: [Course website](https://appliedcryptography.page).
## Compiling LaTeX Materials
Before compiling any of the LaTeX materials (slides, problem sets, lab sheets...), make sure to first install the fonts included in `misc/fonts/` on your system.
## Author & License
Applied Cryptography at the American University of Beirut by Nadim Kobeissi is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

8
assignments/README.md Normal file
View file

@ -0,0 +1,8 @@
# Assignments
This folder contains assignments relevant to the course.
## Contents
- `labs`: Lab session project sheets.
- `problem-sets`: Graded problem sets.

17
assignments/labs/Makefile Normal file
View file

@ -0,0 +1,17 @@
all:
@make password-manager
@make secure-messenger
@make zk-battleship
@make proverif
password-manager:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/labs "password-manager.tex"
secure-messenger:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/labs "secure-messenger.tex"
zk-battleship:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/labs "zk-battleship.tex"
proverif:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/labs "proverif.tex"

9
assignments/labs/README.md Normal file
View file

@ -0,0 +1,9 @@
# Labs
- [x] Password Manager
- [x] Secure Messenger
- [x] [ZK Battleship](https://github.com/nategraf/oscw-zkvms-battleship)
- [ ] [ProofFrog](https://prooffrog.github.io)
- [ ] [Verifpal](https://verifpal.com)
- [x] [ProVerif](https://proverif.inria.fr) or [Tamarin](https://tamarin-prover.com)
- [ ] [CTFs](https://ctftime.org/tasks/?tags=crypto&hidden-tags=crypto) if we have time?

159
assignments/labs/password-manager.tex Executable file
View file

@ -0,0 +1,159 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Lab Assignment: Building a Secure Password Manager}
\subsection*{Overview}
In this lab, you will design and implement a secure password manager application from scratch. This represents your first opportunity to apply cryptographic primitives to build a complete security protocol—albeit one that operates locally without network communication. Password managers are essential security tools that help users generate, store, and manage their credentials for various services. By building one, you'll gain practical experience with fundamental cryptographic primitives, secure storage techniques, and security-focused software design principles. Future lab assignments will build upon these skills by incorporating network components as you develop secure messengers, encrypted synchronization protocols, and other networked security applications.
\subsection*{Learning Objectives}
After completing this lab, you should be able to:
\begin{itemize}
\item Apply cryptographic primitives like key derivation functions and authenticated encryption.
\item Implement secure data storage techniques.
\item Design and build a security-critical application with proper threat modeling.
\item Evaluate the security properties of a password management system.
\end{itemize}
\subsection*{Background}
Password managers solve the problem of creating and remembering strong, unique passwords for multiple services. A password manager typically:
\begin{itemize}
\item Generates cryptographically strong random passwords.
\item Encrypts and securely stores passwords using a master password.
\item Provides convenient access to stored credentials.
\item Protects against various attacks including phishing and data breaches.
\end{itemize}
\subsection*{Requirements}
Your password manager must implement the following core functionality:
\begin{enumerate}
\item \textbf{Master Password Handling:}
\begin{itemize}
\item Derive an encryption key from a master password using a suitable KDF (e.g., Argon2, Scrypt).
\item Implement appropriate security parameters (salt, iterations).
\item Correctly handle key rotation in the event of a master password change.
\end{itemize}
\item \textbf{Password Storage:}
\begin{itemize}
\item Store encrypted passwords with appropriate metadata (website, username).
\item Use authenticated encryption (e.g., AES-GCM) to protect confidentiality and integrity.
\item Implement secure serialization and deserialization.
\end{itemize}
\item \textbf{Password Generation:}
\begin{itemize}
\item Generate cryptographically secure random passwords.
\item Allow configuration of password characteristics (length, character sets).
\end{itemize}
\item \textbf{User Interface:}
\begin{itemize}
\item Create a simple CLI or GUI interface for interaction.
\item Implement basic operations: add, retrieve, update, and delete passwords.
\item Include master password verification.
\item Implement clipboard clearing after use.
\item Add timeout for automatic locking.
\item Include proper error handling without leaking sensitive information.
\end{itemize}
\end{enumerate}
\subsection*{Implementation Guidelines}
\subsubsection*{Step 1: Design}
Begin by creating a threat model for your password manager. Consider:
\begin{itemize}
\item Who are the attackers? (Malware, physical access, remote attackers)
\item What assets are you protecting? (Master password, stored credentials)
\item What are the attack vectors? (Memory dumps, disk access, etc.)
\item What cryptographic protections will you employ?
\end{itemize}
Document your design decisions and security assumptions.
\subsubsection*{Step 2: Cryptographic Building Blocks}
Implement or properly use existing libraries for:
\begin{itemize}
\item Key derivation from the master password.
\item Authenticated encryption of the password database.
\item Secure random password generation.
\end{itemize}
\subsubsection*{Step 3: Core Functionality}
Implement the core functionality:
\begin{itemize}
\item Database creation and loading.
\item Password entry management.
\item Password generation with customizable par ameters.
\end{itemize}
\subsubsection*{Step 4: User Interface}
Create an interface that balances security and usability:
\begin{itemize}
\item Master password input (with appropriate masking).
\item Commands for managing entries.
\item Secure display and clipboard operations.
\end{itemize}
\subsubsection*{Step 5: Security Hardening}
Add security features like:
\begin{itemize}
\item Memory protection techniques.
\item Auto-locking functionality.
\item Input validation and error handling.
\end{itemize}
\subsection*{Deliverables}
Submit the following:
\begin{enumerate}
\item Source code for your password manager.
\item Design document including:
\begin{itemize}
\item Threat model and security assumptions.
\item Description of cryptographic mechanisms used.
\item Design decisions and their rationale.
\end{itemize}
\item User manual explaining how to use your password manager
\item Security analysis discussing:
\begin{itemize}
\item Strengths of your implementation.
\item Limitations and potential vulnerabilities.
\item Suggested improvements for a production version.
\end{itemize}
\end{enumerate}
\subsection*{Evaluation Criteria}
Your project will be evaluated based on:
\begin{itemize}
\item Correctness of cryptographic implementations.
\item Security of the overall design.
\item Completeness of required functionality.
\item Quality of code and documentation.
\item Thoughtfulness of security analysis.
\end{itemize}
\subsection*{Resources}
\begin{itemize}
\item The course textbook and materials on symmetric encryption.
\item Libraries: libsodium, OpenSSL, or equivalent based on your language choice.
\item Research papers on password manager security (see course website).
\end{itemize}
\subsection*{Submission Guidelines}
\begin{itemize}
\item Submit your code as a ZIP archive or through a Git repository.
\item Include all documentation in PDF or Markdown format.
\item Presentations: Prepare a 10-minute presentation demonstrating your password manager.
\end{itemize}
\end{document}

167
assignments/labs/proverif.tex Executable file
View file

@ -0,0 +1,167 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Lab Assignment: Designing and Verifying a TLS-like Protocol using ProVerif}
\subsection*{Overview}
In this lab, you will design and formally verify a Transport Layer Security (TLS)-like protocol using ProVerif, a formal verification tool for cryptographic protocols. This represents your first opportunity to apply formal methods to verify the security properties of a complete cryptographic protocol—one that provides confidentiality, integrity, and authentication for network communications. By designing and verifying this protocol, you'll gain practical experience with cryptographic protocol design, formal verification, and security property specification. Future lab assignments will build upon these skills by incorporating more complex cryptographic protocols and verification scenarios.
\subsection*{Learning Objectives}
After completing this lab, you should be able to:
\begin{itemize}
\item Apply formal verification to analyze security properties of cryptographic protocols.
\item Understand and use the ProVerif verification tool.
\item Design and specify a cryptographic protocol with proper threat modeling.
\item Evaluate protocol security properties such as secrecy, authentication, and forward secrecy.
\end{itemize}
\subsection*{Background}
Formal verification tools like ProVerif allow protocol designers to mathematically verify security properties. In the context of a TLS-like protocol:
\begin{itemize}
\item ProVerif models attackers who have complete control over the communication network.
\item Security properties can be precisely defined and verified, such as confidentiality of session keys.
\item Verification is performed automatically by exploring all possible protocol executions.
\item ProVerif uses symbolic cryptography to reason about cryptographic primitives.
\end{itemize}
\subsection*{Requirements}
Your TLS-like protocol must implement the following core functionality:
\begin{enumerate}
\item \textbf{Protocol Initialization:}
\begin{itemize}
\item Design a secure handshake procedure between client and server.
\item Incorporate key exchange mechanisms (e.g., Diffie-Hellman).
\item Implement proper authentication through digital signatures or certificates.
\end{itemize}
\item \textbf{Key Exchange:}
\begin{itemize}
\item Establish secure session keys between client and server.
\item Ensure forward secrecy for session communications.
\item Protect against Man-in-the-Middle attacks.
\end{itemize}
\item \textbf{Secure Communication:}
\begin{itemize}
\item Design mechanisms for encrypting and authenticating messages.
\item Implement protection against replay and reordering attacks.
\item Ensure secure session termination.
\end{itemize}
\item \textbf{Formal Specification:}
\begin{itemize}
\item Model the protocol in ProVerif's applied pi calculus.
\item Define security properties to be verified.
\item Design appropriate queries to check security properties.
\item Include proper protocol termination and error handling.
\end{itemize}
\end{enumerate}
\subsection*{Implementation Guidelines}
\subsubsection*{Step 1: Design}
Begin by creating a threat model for your TLS-like protocol. Consider:
\begin{itemize}
\item Who are the attackers? (Network adversaries, malicious endpoints)
\item What assets are you protecting? (Session keys, message confidentiality, authentication)
\item What are the attack vectors? (Man-in-the-Middle, replay, downgrade attacks)
\item What cryptographic protections will you employ?
\end{itemize}
Document your design decisions and security assumptions.
\subsubsection*{Step 2: Protocol Specification}
Design your protocol using formal notation:
\begin{itemize}
\item Define message formats and cryptographic operations.
\item Specify the exact sequence of messages exchanged.
\item Define the security properties you expect your protocol to satisfy.
\end{itemize}
\subsubsection*{Step 3: ProVerif Modeling}
Implement your protocol in ProVerif:
\begin{itemize}
\item Model cryptographic primitives using ProVerif's type system.
\item Define processes for client and server roles.
\item Formalize security properties as queries.
\item Set up the attacker model in ProVerif.
\end{itemize}
\subsubsection*{Step 4: Verification}
Verify your protocol's security properties:
\begin{itemize}
\item Run ProVerif to check for secrecy violations.
\item Verify authentication properties.
\item Test for resistance against replay attacks.
\item Verify forward secrecy.
\end{itemize}
\subsubsection*{Step 5: Protocol Refinement}
Improve your protocol based on verification results:
\begin{itemize}
\item Address any vulnerabilities discovered.
\item Optimize the protocol if possible.
\item Document changes and their justifications.
\end{itemize}
\subsection*{Deliverables}
Submit the following:
\begin{enumerate}
\item Protocol specification including:
\begin{itemize}
\item Formal description of your TLS-like protocol.
\item Message sequence diagrams.
\item Cryptographic primitives used and their roles.
\end{itemize}
\item ProVerif code implementing your protocol.
\item Design document including:
\begin{itemize}
\item Threat model and security assumptions.
\item Formal security properties being verified.
\item Design decisions and their rationale.
\end{itemize}
\item Security analysis discussing:
\begin{itemize}
\item Verification results from ProVerif.
\item Strengths of your protocol design.
\item Limitations and potential vulnerabilities.
\item Suggested improvements for a production version.
\end{itemize}
\end{enumerate}
\subsection*{Evaluation Criteria}
Your project will be evaluated based on:
\begin{itemize}
\item Correctness of ProVerif specifications and queries.
\item Security of the overall protocol design.
\item Completeness of required functionality.
\item Quality of code and documentation.
\item Thoughtfulness of security analysis.
\end{itemize}
\subsection*{Resources}
\begin{itemize}
\item The course textbook and materials on cryptographic protocols.
\item ProVerif documentation and examples.
\item TLS 1.3 specification for reference.
\item Research papers on formal verification of security protocols (see course website).
\end{itemize}
\subsection*{Submission Guidelines}
\begin{itemize}
\item Submit your ProVerif code as a ZIP archive or through a Git repository.
\item Include all documentation in PDF or Markdown format.
\item Presentations: Prepare a 10-minute presentation demonstrating your protocol design and verification results.
\end{itemize}
\end{document}

169
assignments/labs/secure-messenger.tex Executable file
View file

@ -0,0 +1,169 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Lab Assignment: Building a Secure Messenger}
\subsection*{Overview}
In this lab, you will design and implement a secure messaging application from scratch. This represents an opportunity to apply cryptographic primitives to build a complete end-to-end encrypted communication system. Secure messengers enable users to exchange private information over untrusted networks while protecting confidentiality, integrity, and authenticity of messages. By building one, you'll gain practical experience with cryptographic protocols, network security, and security-focused software design principles. This lab will require you to implement secure key exchange, encrypted message transmission, and proper security guarantees such as forward secrecy and deniability.
\subsection*{Learning Objectives}
After completing this lab, you should be able to:
\begin{itemize}
\item Apply cryptographic primitives such as public key cryptography and authenticated encryption.
\item Implement secure communication protocols with proper key exchange.
\item Design and build a security-critical networked application with proper threat modeling.
\item Evaluate the security properties of end-to-end encrypted communication systems.
\end{itemize}
\subsection*{Background}
Secure messaging applications provide private communication over potentially compromised networks. A secure messenger typically:
\begin{itemize}
\item Employs end-to-end encryption to ensure only the intended recipient can read messages.
\item Provides forward secrecy so compromise of current keys doesn't expose previous communications.
\item Authenticates correspondents to prevent message forgery and man-in-the-middle attacks.
\item Protects metadata where possible to minimize surveillance risks.
\item Enables secure group communications and file transfers.
\end{itemize}
\subsection*{Requirements}
Your secure messenger must implement the following core functionality:
\begin{enumerate}
\item \textbf{User Identity and Key Management:}
\begin{itemize}
\item Generate cryptographic identities for users (public/private key pairs).
\item Implement secure storage of private keys.
\item Create a mechanism for key exchange and verification.
\item Support key rotation and revocation.
\end{itemize}
\item \textbf{Message Encryption:}
\begin{itemize}
\item Implement end-to-end encryption using a recognized protocol (e.g., Signal Protocol).
\item Use authenticated encryption for message confidentiality and integrity.
\item Support forward secrecy through proper key ratcheting.
\item Implement a mechanism for secure message serialization and deserialization.
\end{itemize}
\item \textbf{Communication Features:}
\begin{itemize}
\item Support one-to-one messaging.
\item Include basic message delivery notifications.
\item Implement message persistence with proper encryption at rest.
\end{itemize}
\item \textbf{User Interface:}
\begin{itemize}
\item Create a simple CLI or GUI interface for interaction.
\item Implement basic operations: send messages, view conversations, and manage contacts.
\item Include proper authentication and session management.
\item Add timeout for automatic logout.
\item Include proper error handling without leaking sensitive information.
\end{itemize}
\end{enumerate}
\subsection*{Implementation Guidelines}
\subsubsection*{Step 1: Design}
Begin by creating a threat model for your secure messenger. Consider:
\begin{itemize}
\item Who are the attackers? (Network adversaries, server operators, malicious contacts)
\item What assets are you protecting? (Message content, metadata, contact information)
\item What are the attack vectors? (TLS interception, server compromise, client malware)
\item What cryptographic protections will you employ?
\end{itemize}
Document your design decisions and security assumptions.
\subsubsection*{Step 2: Cryptographic Building Blocks}
Implement or properly use existing libraries for:
\begin{itemize}
\item Public-key cryptography for identity and initial key exchange.
\item Symmetric key ratcheting for forward secrecy.
\item Authenticated encryption for message protection.
\item Secure random number generation.
\end{itemize}
\subsubsection*{Step 3: Core Functionality}
Implement the core functionality:
\begin{itemize}
\item User registration and identity establishment.
\item Contact discovery and key exchange.
\item Message encryption, transmission, and decryption.
\item Session management and key ratcheting.
\end{itemize}
\subsubsection*{Step 4: User Interface}
Create an interface that balances security and usability:
\begin{itemize}
\item User authentication flow.
\item Conversation view and message composition.
\item Contact management and verification.
\item Security indicators and warnings.
\end{itemize}
\subsubsection*{Step 5: Security Hardening}
Add security features like:
\begin{itemize}
\item Memory protection techniques for cryptographic material.
\item Protection against replay and message reordering attacks.
\item Input validation and error handling.
\item Secure deletion of messages when requested.
\end{itemize}
\subsection*{Deliverables}
Submit the following:
\begin{enumerate}
\item Source code for your secure messenger.
\item Design document including:
\begin{itemize}
\item Threat model and security assumptions.
\item Description of cryptographic mechanisms used.
\item Network protocol specifications.
\item Design decisions and their rationale.
\end{itemize}
\item User manual explaining how to use your secure messenger.
\item Security analysis discussing:
\begin{itemize}
\item Strengths of your implementation.
\item Limitations and potential vulnerabilities.
\item Suggested improvements for a production version.
\end{itemize}
\end{enumerate}
\subsection*{Evaluation Criteria}
Your project will be evaluated based on:
\begin{itemize}
\item Correctness of cryptographic implementations.
\item Security of the overall design and protocol.
\item Completeness of required functionality.
\item Quality of code and documentation.
\item Thoughtfulness of security analysis.
\item Robustness against the threats identified in your model.
\end{itemize}
\subsection*{Resources}
\begin{itemize}
\item The course textbook and materials on public-key cryptography and secure protocols.
\item Libraries: libsodium, OpenSSL, Signal Protocol libraries based on your language choice.
\item Research papers on secure messaging protocols (see course website).
\item Specifications for Signal Protocol, OTR, or Matrix.
\end{itemize}
\subsection*{Submission Guidelines}
\begin{itemize}
\item Submit your code as a ZIP archive or through a Git repository.
\item Include all documentation in PDF or Markdown format.
\item Presentations: Prepare a 10-minute presentation demonstrating your secure messenger.
\end{itemize}
\end{document}

159
assignments/labs/zk-battleship.tex Executable file
View file

@ -0,0 +1,159 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Lab Assignment: Building a Zero-Knowledge Battleship Game}
\subsection*{Overview}
In this lab, you will design and implement a zero-knowledge battleship game using RISC Zero, a zero-knowledge virtual machine (zkVM). This represents your first opportunity to apply zero-knowledge proofs to build a complete cryptographic protocol—one that allows players to validate their moves without revealing the entire game state. Zero-knowledge battleship demonstrates how players can validate that their guesses produced the correct result (hit vs. no hit) while learning nothing about the opponent's board except what is explicitly revealed through gameplay. By building this game, you'll gain practical experience with zero-knowledge proofs, zkVMs, and cryptographic protocol design. Future lab assignments will build upon these skills by incorporating more complex zero-knowledge applications.
\subsection*{Learning Objectives}
After completing this lab, you should be able to:
\begin{itemize}
\item Apply zero-knowledge proofs to create verifiable computations.
\item Understand and use zkVMs, particularly RISC Zero.
\item Design and build a cryptographic protocol with proper threat modeling.
\item Evaluate the security properties of zero-knowledge applications.
\end{itemize}
\subsection*{Background}
Zero-knowledge proofs allow one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any additional information. In the context of a battleship game:
\begin{itemize}
\item Player 1 can prove whether Player 2's guess hit or missed a ship.
\item The proof is verifiable by Player 2 without revealing the full board layout.
\item The game remains secure against cheating because all moves can be verified.
\item zkVMs like RISC Zero allow developers to generate proofs for arbitrary computations.
\end{itemize}
\subsection*{Requirements}
Your zero-knowledge battleship game must implement the following core functionality:
\begin{enumerate}
\item \textbf{Game Initialization:}
\begin{itemize}
\item Create a secure board setup procedure where players place ships.
\item Generate cryptographic commitments to board layouts.
\item Implement proper validation of initial board configurations.
\end{itemize}
\item \textbf{Game Rounds:}
\begin{itemize}
\item Generate zero-knowledge proofs for hit/miss responses using RISC Zero.
\item Verify proofs to ensure honest gameplay.
\item Track game state securely throughout the game.
\end{itemize}
\item \textbf{Game Logic:}
\begin{itemize}
\item Implement standard battleship rules.
\item Detect when a player has won the game.
\item Ensure all game state transitions are verifiable.
\end{itemize}
\item \textbf{User Interface:}
\begin{itemize}
\item Create a simple CLI interface for gameplay.
\item Display the game boards (with appropriate information hiding).
\item Implement commands for making guesses and viewing game status.
\item Include proper error handling without leaking sensitive information.
\end{itemize}
\end{enumerate}
\subsection*{Implementation Guidelines}
\subsubsection*{Step 1: Design}
Begin by creating a threat model for your zero-knowledge battleship game. Consider:
\begin{itemize}
\item Who are the attackers? (Cheating players, observers)
\item What assets are you protecting? (Board layouts, game integrity)
\item What are the attack vectors? (False claims about hits/misses, board manipulation)
\item What cryptographic protections will you employ?
\end{itemize}
Document your design decisions and security assumptions.
\subsubsection*{Step 2: Cryptographic Building Blocks}
Implement or properly use RISC Zero for:
\begin{itemize}
\item Creating guest programs to verify hits and misses.
\item Generating and verifying zero-knowledge proofs.
\item Securing the game state throughout gameplay.
\end{itemize}
\subsubsection*{Step 3: Core Functionality}
Implement the core functionality:
\begin{itemize}
\item Board initialization and commitment.
\item Move validation with zero-knowledge proofs.
\item Game state management and victory detection.
\end{itemize}
\subsubsection*{Step 4: User Interface}
Create an interface that balances security and usability:
\begin{itemize}
\item Board visualization showing appropriate information.
\item Commands for making guesses.
\item Clear indication of proof validation results.
\end{itemize}
\subsubsection*{Step 5: Security Hardening}
Add security features like:
\begin{itemize}
\item Verification of all cryptographic proofs.
\item Protection against replay and timing attacks.
\item Input validation and error handling.
\end{itemize}
\subsection*{Deliverables}
Submit the following:
\begin{enumerate}
\item Source code for your zero-knowledge battleship game.
\item Design document including:
\begin{itemize}
\item Threat model and security assumptions.
\item Description of zero-knowledge mechanisms used.
\item Design decisions and their rationale.
\end{itemize}
\item User manual explaining how to play your game.
\item Security analysis discussing:
\begin{itemize}
\item Strengths of your implementation.
\item Limitations and potential vulnerabilities.
\item Suggested improvements for a production version.
\end{itemize}
\end{enumerate}
\subsection*{Evaluation Criteria}
Your project will be evaluated based on:
\begin{itemize}
\item Correctness of zero-knowledge proof implementations.
\item Security of the overall design.
\item Completeness of required functionality.
\item Quality of code and documentation.
\item Thoughtfulness of security analysis.
\end{itemize}
\subsection*{Resources}
\begin{itemize}
\item The course textbook and materials on zero-knowledge proofs.
\item RISC Zero documentation and examples.
\item Directory structure and README provided for the project.
\item Research papers on zero-knowledge applications (see course website).
\end{itemize}
\subsection*{Submission Guidelines}
\begin{itemize}
\item Submit your code as a ZIP archive or through a Git repository.
\item Include all documentation in PDF or Markdown format.
\item Presentations: Prepare a 10-minute presentation demonstrating your zero-knowledge battleship game.
\end{itemize}
\end{document}

13
assignments/problem-sets/Makefile Normal file
View file

@ -0,0 +1,13 @@
all:
@make problem-set-1
@make problem-set-2
@make problem-set-3
problem-set-1:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/problem-sets "problem-set-1.tex"
problem-set-2:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/problem-sets "problem-set-2.tex"
problem-set-3:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../../website/problem-sets "problem-set-3.tex"

28
assignments/problem-sets/NOTES.md Normal file
View file

@ -0,0 +1,28 @@
# Ideas for later problem sets
```latex
\item (5 points) \textbf{TLS Under Attack:}
An advanced persistent threat (APT) group has compromised several Certificate Authorities and can issue valid certificates for any domain.
\begin{enumerate}
\item Analyze exactly how this compromise allows attacks against TLS connections, even when users see the "secure" padlock icon.
\item Design countermeasures that could be deployed by browser vendors to detect and prevent these attacks. Consider both technical and usability constraints.
\item Evaluate certificate pinning as a solution: when does it work, when does it fail, and how should it be deployed?
\item Compare your solutions to Certificate Transparency. What attacks does CT prevent, and what attacks does it miss?
\end{enumerate}
\item (5 points) \textbf{Signal's Double Ratchet Design Challenge:}
You're designing the next version of Signal's messaging protocol and want to improve upon the current Double Ratchet algorithm.
\begin{enumerate}
\item Analyze the trade-off between security and performance in the current design: why does Signal perform a new DH exchange for each message direction rather than just once per conversation?
\item Design an optimization that reduces the number of DH operations while maintaining the same security properties. What compromises would you accept?
\item Consider a group messaging scenario with 100 participants. How would you adapt your design to provide forward secrecy and post-compromise security for group conversations?
\end{enumerate}
\item (5 points) \textbf{Quantum Timeline Decision Making:}
You're the CTO of a company building a secure messaging app expected to launch in 2028 and remain secure until 2040. Intelligence reports suggest large-scale quantum computers might exist by 2035, but with significant uncertainty (could be 2030 or 2045).
\begin{enumerate}
\item Design a migration strategy that balances current performance needs with future quantum threats. What algorithms do you deploy now, and when do you plan upgrades?
\item Analyze the "harvest now, decrypt later" threat: what data in your system needs protection beyond 2035, and how does this influence your cryptographic choices?
\item Evaluate the trade-offs between early adoption of post-quantum cryptography (larger keys, unproven security) versus delayed migration (quantum vulnerability risk).
\end{enumerate}
```

5
assignments/problem-sets/README.md Normal file
View file

@ -0,0 +1,5 @@
# Problem Sets
- Problem Set 1: Covering lectures 1-1, 1-2 and 1-3.
- Problem Set 2: Covering lectures 1-4, 1-5 and 1-6.
- Problem Set 2: Covering lectures 1-7 and 1-8.

342
assignments/problem-sets/problem-set-1.tex Normal file
View file

@ -0,0 +1,342 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Problem Set 1: Provable Security Foundations}
\begin{tcolorbox}[colframe=OliveGreen!30!white,colback=OliveGreen!5!white]
\textbf{Instructions:} This problem set covers the foundations of provable security from parts 1.1\footnote{\url{https://appliedcryptography.page/slides/1-1.pdf}}, 1.2\footnote{\url{https://appliedcryptography.page/slides/1-2.pdf}} and 1.3\footnote{\url{https://appliedcryptography.page/slides/1-3.pdf}} of the course. Submit your solutions as a neatly formatted PDF. You are encouraged to collaborate with classmates in studying the material, but your submitted solutions must be your own work. For proofs, clearly state your assumptions, steps, and conclusions.
\end{tcolorbox}
\section{Cryptographic Foundations (20 points)}
\subsection{Basic Concepts (10 points)}
\begin{enumerate}
\item (3 points) Define the three primary security goals of cryptography in your own words and provide a real-world example for each that wasn't explicitly mentioned in the lectures.
\item (3 points) Explain Kerckhoff's principle and why it remains fundamental to modern cryptography. Provide an example of a security system that violates this principle and describe the potential consequences.
\item (4 points) Compare and contrast symmetric and asymmetric cryptography:
\begin{enumerate}
\item Explain the fundamental difference in their key management approach.
\item For each type, identify which mathematical or computational assumptions their security typically relies on.
\item Describe a scenario where one would be clearly preferable to the other.
\end{enumerate}
\end{enumerate}
\subsection{Perfect Secrecy (10 points)}
\begin{enumerate}
\item (3 points) Consider a modified one-time pad where we use the bitwise AND ($\land$) operation instead of XOR ($\oplus$):
$\textsf{Enc}(K, M) = K \land M$ and $\textsf{Dec}(K, C) = ?$
\begin{enumerate}
\item Is this scheme correct? If yes, specify the decryption function. If not, explain why.
\item Does this scheme provide perfect secrecy? Justify your answer.
\end{enumerate}
\item (4 points) Consider the following variant of a one-time pad operating on decimal digits (0-9):
$\textsf{Enc}(K, M) = (K + M) \bmod 10$ and $\textsf{Dec}(K, C) = (C - K) \bmod 10$
where $K, M, C \in \{0, 1, 2, \ldots, 9\}$.
\begin{enumerate}
\item Prove that this scheme is correct.
\item Prove that this scheme provides perfect secrecy, assuming $K$ is chosen uniformly at random.
\end{enumerate}
\item (3 points) Consider a one-time pad where the key length is half the message length:
$\textsf{Enc}(K, M) = (K \oplus M_1, K \oplus M_2)$ where $M = (M_1, M_2)$ and $|M_1| = |M_2| = |K|$.
Provide a specific attack that breaks the confidentiality of this scheme, showing clearly the information an attacker can extract from the ciphertext.
\end{enumerate}
\section{Provable Security (20 points)}
\subsection{Libraries and Interchangeability (10 points)}
\begin{enumerate}
\item (5 points) Consider the following libraries:
\begin{center}
\sslinked{
\sslibrary{}{1}{
\sslibrarysubroutine{init}{}{
$K \twoheadleftarrow \bits^n$
}{1}\\[1em]
\sslibrarysubroutine{query}{M}{
return $K \oplus M$
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{2}{
\sslibrarysubroutine{init}{}{
$R_1 \twoheadleftarrow \bits^n$ \\
$R_2 \twoheadleftarrow \bits^n$
}{1}\\[1em]
\sslibrarysubroutine{query}{M}{
if $M = R_1$ return $R_2$ \\
else return $M \oplus R_1 \oplus R_2$
}{1}
}{1}
}
\end{center}
Are these libraries interchangeable? Either prove they are interchangeable or provide a distinguisher program that can tell them apart with non-negligible probability.
\item (5 points) For each of the following pairs of libraries, state whether they are interchangeable and briefly justify your answer:
\begin{enumerate}
\item
\begin{center}
\sslinked{
\sslibrary{}{A}{
\sslibrarysubroutine{f}{x}{
$y \twoheadleftarrow \bits^n$ \\
return $y$
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{B}{
\sslibrarysubroutine{f}{x}{
$y \twoheadleftarrow \bits^n$ \\
$z \twoheadleftarrow \bits^n$ \\
return $y$
}{1}
}{1}
}
\end{center}
\item
\begin{center}
\sslinked{
\sslibrary{}{C}{
$K \twoheadleftarrow \bits^n$\\[1em]
\sslibrarysubroutine{enc}{M}{
$C \coloneq K \oplus M$ \\
return $C$
}{1}\\[1em]
\sslibrarysubroutine{dec}{C}{
$M \coloneq K \oplus C$ \\
return $M$
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{D}{
\sslibrarysubroutine{enc}{M}{
$C \twoheadleftarrow \bits^n$ \\
return $C$
}{1}\\[1em]
\sslibrarysubroutine{dec}{C}{
$M \twoheadleftarrow \bits^n$ \\
return $M$
}{1}
}{1}
}
\end{center}
\end{enumerate}
\end{enumerate}
\subsection{Security Proofs (10 points)}
\begin{enumerate}
\item (5 points) Let $\Sigma = (\textsf{KeyGen}, \textsf{Enc}, \textsf{Dec})$ be a secure encryption scheme for messages in $\bits^n$. Consider the following modified scheme $\Sigma' = (\textsf{KeyGen}', \textsf{Enc}', \textsf{Dec}')$:
\begin{align*}
\textsf{KeyGen}'() & = K \twoheadleftarrow \textsf{KeyGen}() \\
\textsf{Enc}'(K, M) & = (C_1, C_2) \text{ where } C_1 \twoheadleftarrow \textsf{Enc}(K, M) \text{ and } C_2 \twoheadleftarrow \textsf{Enc}(K, M \oplus 1^n) \\
\textsf{Dec}'(K, (C_1, C_2)) & = \textsf{Dec}(K, C_1)
\end{align*}
Determine whether $\Sigma'$ is a secure encryption scheme. If it is secure, provide a formal proof. If it is not secure, describe a concrete attack that breaks its confidentiality and explain why the attack works.
\item (5 points) Consider the following game between a challenger and an adversary $\mathcal{A}$:
\begin{enumerate}
\item The adversary selects two messages $M_0$ and $M_1$ of the same length.
\item The challenger selects a uniform random bit $b \twoheadleftarrow \bits$ and a uniform random key $K \twoheadleftarrow \bits^n$.
\item The challenger computes $C = K \oplus M_b$ and gives $C$ to the adversary.
\item The adversary outputs a bit $b'$ as its guess for $b$.
\end{enumerate}
Prove that for any adversary $\mathcal{A}$, the probability that $b' = b$ is exactly $1/2$. Explain what this result tells us about the security of the one-time pad.
\end{enumerate}
\section{Computational Cryptography (30 points)}
\subsection{Computational Security Concepts (15 points)}
\begin{enumerate}
\item (5 points) Explain why computational security is important in practice despite the existence of information-theoretic security. Discuss the limitations of both approaches.
\item (4 points) Consider a brute-force attack on AES-128:
\begin{enumerate}
\item Using the monetary cost table provided in the lecture, estimate how much it would cost to try all possible keys.
\item Discuss whether the computational approach to security makes sense in light of this cost.
\end{enumerate}
\item (3 points) Define a negligible function formally. Then determine which of the following functions are negligible (where $\lambda$ is the security parameter):
\begin{enumerate}
\item $f_1(\lambda) = 2^{-\lambda}$
\item $f_2(\lambda) = \lambda^{-\log \lambda}$
\item $f_3(\lambda) = 2^{-\sqrt{\lambda}}$
\item $f_4(\lambda) = \frac{1}{\lambda \cdot 2^{\lambda/2}}$
\end{enumerate}
\item (3 points) The ``birthday paradox'' is crucial for understanding many cryptographic attacks. If a hash function produces outputs of length $n$ bits:
\begin{enumerate}
\item Approximately how many random inputs would you need to hash before finding a collision with 50\% probability?
\item How many bits of output would a hash function need to be reasonably secure against birthday attacks for the next decade?
\end{enumerate}
\end{enumerate}
\subsection{Distinguishability and Bad Events (15 points)}
\begin{enumerate}
\item (6 points) Consider the following two libraries that implement a 256-bit hash function:
\begin{center}
\sslinked{
\sslibrary{}{real}{
\sslibrarysubroutine{hash}{X}{
return SHA-256(x)
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{rand}{
$L \coloneq$ [\ ]\\[1em]
\sslibrarysubroutine{hash}{X}{
if $L[X]$ undefined:\\
\quad $L[X] \twoheadleftarrow \bits^{256}$\\
return $L[X]$
}{1}
}{1}
}
\end{center}
\begin{enumerate}
\item Describe the ``bad event'' that would allow these libraries to be distinguished.
\item If an adversary is limited to $q$ queries, what is the probability of triggering this bad event?
\item Using the ``bad event'' proof technique, show that these libraries are computationally indistinguishable when $q$ is polynomial in the security parameter.
\end{enumerate}
\item (4 points) Consider the following two libraries:
\begin{center}
\sslinked{
\sslibrary{}{1}{
\sslibrarysubroutine{sample}{}{
$X \twoheadleftarrow \bits^n$ \\
$Y \coloneq X \oplus 1^n$ \\
return $(X, Y)$
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{2}{
\sslibrarysubroutine{sample}{}{
$Y \twoheadleftarrow \bits^n$ \\
$X \coloneq Y \oplus 1^n$ \\
return $(X, Y)$
}{1}
}{1}
}
\end{center}
Use the hybrid proof technique to show these libraries are interchangeable. Clearly describe each intermediate hybrid library.
\item (5 points) Consider a PRF $F: \bits^n \times \bits^n \rightarrow \bits^n$ and the following two libraries:
\begin{center}
\sslinked{
\sslibrary{}{{\text{PRF}}}{
$K \twoheadleftarrow \bits^n$\\[1em]
\sslibrarysubroutine{query}{x}{
return $F(K, X)$
}{1}
}{1}
}{\approxeq}{
\sslibrary{}{rand}{
$L \coloneq$ [\ ]\\[1em]
\sslibrarysubroutine{query}{x}{
if $L[X]$ undefined:\\
\quad $L[X] \twoheadleftarrow \bits^n$\\
return $L[X]$
}{1}
}{1}
}
\end{center}
Suppose we have a program $\mathcal{A}$ that can distinguish between these libraries with advantage $\varepsilon$. Construct a program $\mathcal{B}$ that uses $\mathcal{A}$ as a subroutine to distinguish a PRF from a truly random function with the same advantage $\varepsilon$.
\end{enumerate}
\section{Application of Cryptographic Principles (30 points)}
\begin{enumerate}
\item (10 points) \textbf{Block Cipher Mode Analysis}
The lecture demonstrated how ECB mode reveals patterns in the plaintext. For each of the following block cipher modes, explain:
\begin{enumerate}
\item How the encryption and decryption work.
\item What would happen if the same key and IV (when applicable) were reused for multiple messages.
\item A specific real-world situation where this mode would be most appropriate.
\end{enumerate}
Modes to analyze:
\begin{enumerate}
\item Cipher Block Chaining (CBC)
\item Counter Mode (CTR)
\end{enumerate}
\item (10 points) \textbf{One-Time Pad in the Real World}
A startup claims to have developed a ``quantum-resistant ultra-secure messaging system'' based on the one-time pad. They provide the following details:
\begin{itemize}
\item The system uses a hardware random number generator to produce one-time pads.
\item Each user receives a 1TB USB drive containing pre-generated pad data during account registration.
\item When sending a message, the app encrypts it with a portion of the pad, marks that portion as used, and sends the ciphertext.
\item When the user has used 80\% of their pad, the app automatically requests a new USB drive.
\end{itemize}
Provide a detailed critique of this system:
\begin{enumerate}
\item Identify at least three practical problems with this implementation.
\item Explain how each problem compromises security or usability.
\item Suggest improvements to address each issue while maintaining the theoretical security of OTP.
\end{enumerate}
\item (10 points) \textbf{Symmetric Encryption Protocol Analysis}
A software company is implementing a secure communication protocol for their instant messaging application. They propose the following scheme:
\begin{itemize}
\item Each user generates a random 128-bit key $K$ during account creation.
\item To send a message $M$, the sender computes $C = K \oplus M$ and transmits $C$.
\item When two users want to communicate, they first exchange their keys through a ``top secret channel'' established by the company's server.
\item The company claims their protocol is ``as secure as one-time pad'' because they use the XOR operation.
\end{itemize}
Address the following aspects of this system:
\begin{enumerate}
\item Using the provable security framework discussed in class, analyze whether this scheme provides the confidentiality properties claimed by the company.
\item Identify at least three major security vulnerabilities in the described approach.
\item The company is considering having users generate new keys daily instead of just once. Explain whether this modification would address the vulnerabilities you identified.
\item Propose a modified protocol that would significantly improve security while still using only symmetric cryptography concepts covered in class so far. Justify your choices using the security principles we've discussed.
\end{enumerate}
\end{enumerate}
\begin{tcolorbox}[colframe=EarthBrown!30!white,colback=EarthBrown!5!white]
\textbf{Bonus Challenge (20 extra points):} The discrete logarithm problem is fundamental to many cryptographic systems. Consider a cyclic group $G$ of prime order $p$ with generator $g$. The discrete logarithm problem is: given $h \in G$, find $x$ such that $g^x = h$.
Imagine a scenario where the discrete logarithm problem could be solved efficiently. Select one modern cryptographic protocol that relies on the hardness of this problem, and analyze:
\begin{enumerate}
\item The specific impact on the protocol's security.
\item How the protocol would need to be modified to remain secure.
\item Whether any alternative mathematical problems could serve as suitable replacements.
\end{enumerate}
Your answer should demonstrate deep understanding of both the protocol and the underlying mathematical principles.
\end{tcolorbox}
\end{document}

259
assignments/problem-sets/problem-set-2.tex Normal file
View file

@ -0,0 +1,259 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Problem Set 2: Symmetric Cryptography}
\begin{tcolorbox}[colframe=OliveGreen!30!white,colback=OliveGreen!5!white]
\textbf{Instructions:} This problem set covers topics in provable security from parts 1.4\footnote{\url{https://appliedcryptography.page/slides/1-4.pdf}}, 1.5\footnote{\url{https://appliedcryptography.page/slides/1-5.pdf}} and 1.6\footnote{\url{https://appliedcryptography.page/slides/1-6.pdf}} of the course. Submit your solutions as a neatly formatted PDF. You are encouraged to collaborate with classmates in studying the material, but your submitted solutions must be your own work. For proofs, clearly state your assumptions, steps, and conclusions.
\end{tcolorbox}
\section{Pseudorandomness (20 points)}
\subsection{Pseudorandom Generators (10 points)}
\begin{enumerate}
\item (3 points) Explain the limitations of the one-time pad for practical encryption and why pseudorandom generators (PRGs) are needed in modern cryptographic systems.
\item (3 points) Analyze the security implications of the following PRG construction, where $G$ is a secure PRG:
\begin{align*}
H(S) = A \| B \| C \| D \text{ where } A \| B = G(S) \text{ and } C \| D = G(B)
\end{align*}
Determine whether $H$ is a secure PRG. If not, provide a distinguisher that can tell apart $H(S)$ from a truly random string with non-negligible advantage.
\item (4 points) Consider the stream cipher RC4:
\begin{enumerate}
\item Describe the key components of RC4's design and how it generates a pseudorandom keystream.
\item Explain two significant weaknesses that led to RC4 being considered cryptographically broken today.
\item What modern alternatives would you recommend as replacements for RC4, and why?
\end{enumerate}
\end{enumerate}
\subsection{Pseudorandom Functions and Permutations (10 points)}
\begin{enumerate}
\item (3 points) Consider the following PRF construction: $F(K, X) = G(K) \oplus X$, where $G$ is a secure PRG.
\begin{enumerate}
\item Is $F$ a secure PRF? If not, describe a distinguisher that can effectively tell $F$ apart from a random function.
\item Explain how this example illustrates the ``Golden Rule of PRFs.''
\end{enumerate}
\item (4 points) For Feistel ciphers:
\begin{enumerate}
\item Explain why a 2-round Feistel cipher cannot be a secure pseudorandom permutation (PRP).
\item Prove that Feistel ciphers are always permutations, regardless of the security of their round functions.
\end{enumerate}
\item (3 points) Compare and contrast PRFs and PRPs:
\begin{enumerate}
\item Explain the key differences in their definitions and properties.
\item Describe how PRPs can be ``downgraded'' to PRFs, but not necessarily vice versa.
\item Explain why collisions are inevitable for PRFs but not for PRPs.
\end{enumerate}
\end{enumerate}
\section{Chosen-Plaintext and Chosen-Ciphertext Attacks (20 points)}
\subsection{CPA Security (10 points)}
\begin{enumerate}
\item (5 points) Consider the CPA security definition:
\begin{center}
\sslinked{
\sslibrary{\Sigma}{cpa-real}{
$K \twoheadleftarrow \Sigma.\mathcal{K}$\\[1em]
\sslibrarysubroutine{cpa.enc}{M}{
$C \coloneq \Sigma.\texttt{Enc}(K, M)$\\
return $C$
}{1}
}{0.8}
}{\approxeq}{
\sslibrary{\Sigma}{cpa-rand}{
\sslibrarysubroutine{cpa.enc}{M}{
$C \twoheadleftarrow \Sigma.\mathcal{C}(|M|)$\\
return $C$
}{1}
}{0.8}
}
\end{center}
\begin{enumerate}
\item Explain why deterministic encryption schemes always fail CPA security.
\item Construct a simple distinguisher program that can break the CPA security of any deterministic encryption scheme.
\item Analyze what practical security vulnerabilities exist in systems that use non-CPA-secure encryption.
\end{enumerate}
\item (5 points) For each of the following encryption schemes, determine whether it achieves CPA security. If not, provide a specific attack:
\begin{enumerate}
\item $\textsf{Enc}(K, M) = (R, F(K, R) \oplus M)$ where $R \twoheadleftarrow \{0,1\}^{\lambda}$ and $F$ is a secure PRF.
\item $\textsf{Enc}(K, M) = (R, F(K, M) \oplus R)$ where $R \twoheadleftarrow \{0,1\}^{\lambda}$ and $F$ is a secure PRF.
\item AES in Electronic Codebook (ECB) mode.
\item AES in Counter (CTR) mode with a randomly chosen IV.
\end{enumerate}
\end{enumerate}
\subsection{CCA Security and Authenticated Encryption (10 points)}
\begin{enumerate}
\item (3 points) Format oracle attacks:
\begin{enumerate}
\item Explain how the null-oracle attack works against CTR mode encryption and why it's devastating despite CTR mode being CPA-secure.
\item Describe a real-world scenario where a format oracle might be inadvertently exposed in a cryptographic system.
\item Calculate the approximate number of oracle queries needed to recover a 1 KB file using the null-oracle attack, and explain why this is practical for an attacker.
\end{enumerate}
\item (4 points) For the following encryption scheme constructions, determine whether each provides CCA security and/or authenticated encryption (AE). Justify your answers with brief explanations:
\begin{enumerate}
\item Encrypt-then-MAC: $C = \textsf{Enc}(K_e, M)$, $T = \textsf{MAC}(K_m, C)$, output $(C, T)$
\item Encrypt-and-MAC: $C = \textsf{Enc}(K_e, M)$, $T = \textsf{MAC}(K_m, M)$, output $(C, T)$
\item MAC-then-encrypt: $T = \textsf{MAC}(K_m, M)$, $C = \textsf{Enc}(K_e, M\|T)$, output $C$
\item Explain a scenario where replay attacks could succeed even against a system using authenticated encryption, and how associated data (AD) addresses this vulnerability.
\end{enumerate}
\item (3 points) AES-GCM (Galois/Counter Mode):
\begin{enumerate}
\item Explain how AES-GCM combines CTR mode encryption with Galois field multiplication for authentication. What security advantages does this provide over using separate encryption and MAC algorithms?
\item Describe the critical security implications of nonce reuse in AES-GCM. What specific vulnerabilities arise when the same nonce is used for multiple messages?
\item AES-GCM is sometimes implemented with different tag lengths. Analyze the security tradeoffs when using 128-bit tags versus 64-bit or 32-bit tags.
\item Aside from nonce reuse, what is an unexpected vulnerability in AES-GCM that developers and engineers might not be aware of, but that might significantly impact the security of their software?
\end{enumerate}
\end{enumerate}
\section{Collision-Resistant Hash Functions (30 points)}
\subsection{Hash Function Properties (15 points)}
\begin{enumerate}
\item (5 points) Collision resistance:
\begin{enumerate}
\item Explain why collisions must exist in any hash function that maps arbitrary-length inputs to fixed-length outputs.
\item Using the birthday paradox, calculate approximately how many hashes must be computed to find a collision with 50\% probability in a 256-bit secure hash function.
\item Describe a practical attack scenario where finding hash collisions would compromise a security system.
\end{enumerate}
\item (5 points) Hash function construction:
\begin{enumerate}
\item Compare and contrast the Merkle-Damgård construction (used in SHA-2) and the Sponge construction (used in SHA-3).
\item Explain how length extension attacks work against Merkle-Damgård hash functions and why the Sponge construction is resistant to these attacks.
\item Describe the HMAC construction and explain how it protects against length extension attacks.
\end{enumerate}
\item (5 points) Hash function evolution:
\begin{enumerate}
\item Describe the successful attacks against MD5 and SHA-1 that led to their deprecation.
\item Explain the concept of chosen-prefix collisions and why they are particularly dangerous for certificate authorities.
\item Compare the security of SHA-2 and SHA-3 against known cryptanalytic techniques.
\end{enumerate}
\end{enumerate}
\subsection{Password Hashing (15 points)}
\begin{enumerate}
\item (5 points) For each of the following password storage approaches, analyze the security implications if a server database is compromised:
\begin{enumerate}
\item Storing passwords in plaintext.
\item Encrypting passwords with a key stored on the same server.
\item Storing unsalted SHA-256 hashes of passwords.
\item Storing salted SHA-256 hashes of passwords.
\item Using a specialized password hashing function like Scrypt.
\end{enumerate}
\item (5 points) Salting:
\begin{enumerate}
\item Explain how salt protects against precomputation attacks like rainbow tables.
\item Calculate the storage requirements for properly salted password hashes, assuming 10,000 users, 16-byte salts, and 32-byte hash outputs.
\item Describe best practices for generating and storing salts.
\end{enumerate}
\item (5 points) Specialized password hashing functions:
\begin{enumerate}
\item Explain why memory-hard functions like Scrypt provide better protection against specialized hardware attacks compared to PBKDF2.
\item Describe how each of Scrypt's parameters (N, r, p) affect its security and performance.
\item Compare the relative speeds of SHA-256, PBKDF2, and Scrypt for password hashing, and explain the security implications of these speed differences.
\end{enumerate}
\end{enumerate}
\section{Applied Cryptography Case Studies (30 points)}
\begin{enumerate}
\item (10 points) \textbf{Block Cipher Modes Analysis}
With reference to the block cipher modes covered in lectures 1-4, 1-5, and 1-6, analyze the following scenarios:
\begin{enumerate}
\item A secure file storage application needs to encrypt user files at rest. Compare CBC, CTR, and AES-GCM modes for this application, discussing:
\begin{itemize}
\item Performance implications for large files.
\item Error propagation if parts of the ciphertext are corrupted.
\item The security implications of IV/nonce reuse.
\item Data integrity guarantees and the advantages of authenticated encryption with AES-GCM.
\end{itemize}
\item A real-time messaging application needs to encrypt short messages with minimal latency. Compare CBC, CTR, and AES-GCM modes for this application, discussing:
\begin{itemize}
\item Parallelizability for encryption/decryption.
\item Suitability for streaming data.
\item Protection against chosen-ciphertext attacks.
\item How AES-GCM addresses authentication needs compared to unauthenticated modes.
\end{itemize}
\item For AES-GCM specifically:
\begin{itemize}
\item Explain the security impact of nonce reuse in AES-GCM compared to nonce reuse in CTR mode.
\item Discuss the performance tradeoffs of AES-GCM compared to using separate encryption (CTR mode) and authentication (HMAC).
\item Explain how AES-GCM's authenticated encryption properties protect against attacks that would succeed against CBC or CTR modes.
\end{itemize}
\end{enumerate}
\item (10 points) \textbf{Hash Function Security Analysis}
A software update system uses hash functions to verify the integrity of downloads. The system works as follows:
\begin{itemize}
\item The software vendor posts SHA-1 hashes of legitimate update files on their HTTPS website.
\item Users download the update file over HTTP (not HTTPS) for bandwidth efficiency.
\item The update client verifies the downloaded file by computing its SHA-1 hash and comparing it to the hash obtained from the HTTPS website.
\item If the hashes match, the update is installed automatically.
\end{itemize}
Analyze this system:
\begin{enumerate}
\item Identify at least three security vulnerabilities in this design.
\item For each vulnerability, describe a specific attack scenario.
\item Propose improvements to address each vulnerability while maintaining performance and usability.
\item Design a more secure alternative system using modern cryptographic primitives discussed in class.
\end{enumerate}
\item (10 points) \textbf{Password Management System Design}
You are designing a password management system for a new web application with the following requirements:
\begin{itemize}
\item Users must be able to securely recover their account if they forget their password.
\item The system must be resistant to offline dictionary attacks if the database is compromised.
\item The system must support high-performance authentication for a large user base.
\item The system should detect and prevent credential stuffing attacks.
\end{itemize}
Design and analyze a complete solution:
\begin{enumerate}
\item Specify which cryptographic primitives you would use for password storage and why.
\item Describe your password recovery mechanism and analyze its security properties.
\item Explain how your system balances security and performance requirements.
\item Analyze potential vulnerabilities in your design and how they are mitigated.
\end{enumerate}
\end{enumerate}
\begin{tcolorbox}[colframe=EarthBrown!30!white,colback=EarthBrown!5!white]
\textbf{Bonus Challenge (20 extra points):} The security of AES and other block ciphers depends on their resistance to various forms of cryptanalysis. Research and analyze one of the following advanced attacks:
\begin{enumerate}
\item \textbf{Side-channel attacks}: Explain how timing attacks, power analysis, or cache attacks can leak information about encryption keys in practical implementations of AES.
\item \textbf{Related-key attacks}: Describe how related-key attacks work against block ciphers and why they are significant even when normal usage involves only unrelated keys.
\item \textbf{Quantum attacks}: Analyze the impact of Grover's algorithm on the security of AES with different key sizes (128, 192, 256 bits) and discuss appropriate post-quantum key length recommendations.
\end{enumerate}
Your answer should include: a description of the attack, its practical feasibility, relevant examples of successful implementations against real systems, and appropriate countermeasures.
\end{tcolorbox}
\end{document}

225
assignments/problem-sets/problem-set-3.tex Normal file
View file

@ -0,0 +1,225 @@
\documentclass[10pt,a4paper,american]{article}
\newcommand{\aublogopath}{../../website/res/img/aub_black.png}
\usepackage{../../misc/macros/joc}
\usepackage{../../misc/fonts/fonts}
\usepackage{../../misc/macros/classhandout}
\begin{document}
\classhandoutheader
\section*{Problem Set 3: Asymmetric Cryptography}
\begin{tcolorbox}[colframe=OliveGreen!30!white,colback=OliveGreen!5!white]
\textbf{Instructions:} This problem set covers topics in provable security from parts 1.7\footnote{\url{https://appliedcryptography.page/slides/1-7.pdf}} and 1.8\footnote{\url{https://appliedcryptography.page/slides/1-8.pdf}} of the course. Submit your solutions as a neatly formatted PDF. You are encouraged to collaborate with classmates in studying the material, but your submitted solutions must be your own work. For proofs, clearly state your assumptions, steps, and conclusions.
\end{tcolorbox}
\section{Cryptographic Hardness and Real-World Implications (20 points)}
\subsection{Breaking Cryptography: Attack Scenarios (10 points)}
\begin{enumerate}
\item (5 points) \textbf{The Cryptographic Apocalypse Scenario:}
Imagine you wake up tomorrow to headlines: \textit{``Breakthrough Algorithm Solves P vs NP - Computer Scientists Prove P = NP!''}
\begin{enumerate}
\item As the Chief Security Officer of a major bank, write a crisis response memo outlining which systems fail immediately, which have grace periods, and what emergency measures you would implement.
\item Design an alternative security model for online banking that could work in a post-P=NP world. What assumptions would you rely on instead?
\item Analyze why NP-complete problems, despite being \textit{``hard,''} wouldn't save us in this scenario. What's the fundamental difference between NP-complete hardness and cryptographic hardness?
\end{enumerate}
\item (5 points) \textbf{The Weak DH Parameters Problem:}
A security researcher discovers that a popular cryptographic library has been generating Diffie-Hellman parameters where the prime $p$ satisfies $p-1$ having many small factors, making 75\% of generated groups vulnerable to Pohlig-Hellman attacks that reduce the discrete log problem to much smaller subgroups.
\begin{enumerate}
\item Evaluate whether this discovery completely breaks Diffie-Hellman or only partially weakens it. Consider both the mathematical impact and practical deployment consequences.
\item Design a strategy for systems using this library: should they immediately regenerate all parameters, implement parameter validation, or pursue a different approach?
\item Compare this scenario to a hypothetical breakthrough that reduces the discrete logarithm problem in prime-order groups by a factor of $2^{20}$ but still leaves it exponential. Which vulnerability would be more urgent to address and why?
\end{enumerate}
\end{enumerate}
\subsection{Discrete Logarithm Security Architecture (10 points)}
\begin{enumerate}
\item (5 points) \textbf{The Weak Parameter Disaster:}
Your security audit discovers that a legacy system has been using $p = 2047$ (which factors as $23 \times 89$) for Diffie-Hellman key exchange, and the generator $g = 2$.
\begin{enumerate}
\item Analyze exactly why this parameter choice is catastrophically weak. Estimate how long it would take an attacker with a modern laptop to break this system.
\item Design an emergency response plan: how do you migrate users to secure parameters while maintaining service availability?
\item Compare the security implications if the system had instead used a proper 2048-bit prime but with a generator that only generates a small subgroup.
\end{enumerate}
\item (5 points) \textbf{Elliptic Curve vs. Finite Field Trade-off Analysis:}
You're designing a cryptographic protocol for IoT devices with severe computational and bandwidth constraints.
\begin{enumerate}
\item Compare elliptic curve and finite field DLP for your use case: which offers better security per bit of key size, and which offers better computational performance?
\item Analyze why index calculus attacks work against finite fields but not elliptic curves. How does this fundamental difference affect your security margins?
\item Design a hybrid approach that uses both elliptic curves and finite fields strategically. When might this provide benefits over using just one?
\end{enumerate}
\end{enumerate}
\section{Diffie-Hellman in Hostile Environments (20 points)}
\subsection{Attack and Defense Scenarios (10 points)}
\begin{enumerate}
\item (5 points) \textbf{The Perfect Man-in-the-Middle:}
An attacker has complete control over the network between Alice and Bob, can modify any message, and can initiate connections that appear to come from either party.
\begin{enumerate}
\item Design the most effective man-in-the-middle attack against unauthenticated Diffie-Hellman. Your attack should be undetectable to Alice and Bob during the key exchange.
\item Alice and Bob have never met but each has the other's public key fingerprint written on a piece of paper. Design an authentication protocol that defeats your attack using only these fingerprints.
\item Compare your fingerprint-based solution to certificate authorities and web-of-trust models. What are the usability and security trade-offs?
\item The attacker now has quantum capabilities. How does this change your attack and defense strategies?
\end{enumerate}
\item (5 points) \textbf{The Paranoid Whistleblower Scenario:}
A whistleblower needs to securely communicate with a journalist. They assume the government monitors all internet traffic, has compromised most Certificate Authorities, and can perform man-in-the-middle attacks on any connection.
\begin{enumerate}
\item Design a key exchange protocol for this scenario using only methods available to ordinary civilians (no specialized hardware or pre-shared secrets).
\item Analyze what happens if the government can also compromise one of their devices after the key exchange. How can you provide forward secrecy?
\item Compare your solution to existing tools like Tor, Signal, and SecureDrop. What additional protection does your design provide?
\end{enumerate}
\end{enumerate}
\subsection{Protocol Design Challenge (10 points)}
\begin{enumerate}
\item (10 points) \textbf{SSH Trust-on-First-Use Analysis:}
Your organization wants to deploy SSH across 10,000 servers, but the current TOFU model creates security and usability problems at scale.
\begin{enumerate}
\item Analyze specific attack scenarios where the TOFU model fails in practice. When are users most vulnerable?
\item Design an improved authentication model that maintains SSH's simplicity while providing better security guarantees than pure TOFU.
\item Compare your solution to proposals like DNS-based SSH public key distribution (SSHFP records) and OAuth-based SSH certificates. What are the deployment challenges for each approach?
\end{enumerate}
\end{enumerate}
\clearpage
\section{Elliptic Curve Security Engineering (30 points)}
\subsection{Curve Selection Under Pressure (15 points)}
\begin{enumerate}
\item (5 points) \textbf{The Government Backdoor Controversy:}
You're the security architect for a new messaging app. Cryptographers are debating whether NIST P-256 contains a government backdoor, while Curve25519 offers better security properties but less widespread hardware support.
\begin{enumerate}
\item Analyze the specific concerns about NIST curves: what would a backdoor look like, and how could it be exploited without breaking the underlying mathematical problems?
\item Design a risk assessment framework for choosing between P-256 and Curve25519. What factors should influence your decision?
\item Your legal team reports that several countries require NIST-compliant cryptography for government sales. How does this constraint affect your technical decision?
\item Propose a solution that addresses both the backdoor concerns and the compliance requirements. What compromises would you make?
\end{enumerate}
\item (5 points) \textbf{The Invalid Curve Attack Scenario:}
A security researcher discovers that your ECDH implementation doesn't validate input points, making it vulnerable to invalid curve attacks.
\begin{enumerate}
\item Design a specific attack exploiting this vulnerability. What information can an attacker extract, and how long would the attack take?
\item Analyze why this attack works: what mathematical properties of elliptic curves does it exploit?
\item Develop a comprehensive input validation strategy that prevents this attack class. What performance impact does your solution have?
\item Compare this vulnerability to other implementation mistakes like reusing nonces in ECDSA. Which class of error is more dangerous in practice?
\end{enumerate}
\item (5 points) \textbf{Mobile Performance Optimization Challenge:}
Your mobile app needs to perform thousands of ECDH operations per minute on low-end smartphones, but battery life and performance are critical concerns.
\begin{enumerate}
\item Compare the performance characteristics of different elliptic curves for your use case. Consider both computational cost and memory usage.
\item Design an optimization strategy that balances security and performance. Would you use precomputed tables, special curve forms, or other techniques?
\item Analyze the security implications of your optimizations: what new attack surfaces do they create?
\item Evaluate whether quantum resistance should influence your current design decisions, given the mobile hardware lifecycle.
\end{enumerate}
\end{enumerate}
\subsection{Implementation Vulnerability Analysis (15 points)}
\begin{enumerate}
\item (5 points) \textbf{The PlayStation 3 Forensics Challenge:}
You're a digital forensics expert investigating cryptocurrency theft. You discover that the thief's wallet software reused nonces in ECDSA signatures, similar to the PlayStation 3 vulnerability.
\begin{enumerate}
\item Design a forensic analysis procedure to recover the private key from blockchain transaction signatures. What information do you need, and how would you process it?
\item Estimate how many transactions with reused nonces you would need to guarantee key recovery. How does this depend on the specific nonce reuse pattern?
\item Develop a tool to scan existing blockchains for this vulnerability. What would you look for, and how would you optimize the search?
\item Analyze the broader implications: if wallet software commonly had this bug, what percentage of cryptocurrency could be at risk?
\end{enumerate}
\item (5 points) \textbf{Side-Channel Attack Laboratory:}
You're tasked with testing an embedded device's ECDSA implementation for side-channel vulnerabilities.
\begin{enumerate}
\item Design a timing attack against variable-time scalar multiplication. What information would you measure, and how would you extract the private key?
\item Develop countermeasures that maintain performance while resisting your attack. What constant-time techniques would you implement?
\item Analyze power analysis attacks: how would an attacker use power consumption traces to recover cryptographic keys?
\item Evaluate the trade-offs between security and performance for different countermeasures. Which threats should you prioritize defending against?
\end{enumerate}
\item (5 points) \textbf{The Ed25519 Validation Crisis:}
You discover that two widely-used Ed25519 libraries accept different signatures as valid for the same message and public key, breaking interoperability.
\begin{enumerate}
\item Investigate what causes this inconsistency: what validation steps do different implementations handle differently?
\item Analyze the security implications: could an attacker exploit these differences to create practical attacks?
\item Design a test suite to identify which Ed25519 implementations are compatible with each other. What edge cases would you test?
\item Propose a strategy for the cryptographic community to resolve this issue without breaking existing deployments.
\end{enumerate}
\end{enumerate}
\section{Applied Cryptography Case Studies (30 points)}
\begin{enumerate}
\item (10 points) \textbf{Key Exchange Protocol Design}
You are designing a secure messaging application that needs to establish encrypted communication channels between users who have never communicated before. The application must work on mobile devices with limited computational resources and intermittent network connectivity.
\begin{enumerate}
\item Design a complete key exchange protocol using the cryptographic primitives from lectures 1.7 and 1.8. Your design should address:
\begin{itemize}
\item Initial key establishment between strangers
\item Authentication to prevent man-in-the-middle attacks
\item Forward secrecy for long-term security
\item Efficiency for mobile devices
\end{itemize}
\item Analyze the security properties of your protocol. What attacks does it defend against, and what are its limitations?
\item Discuss how your protocol would handle practical issues like key fingerprint verification and key rotation.
\end{enumerate}
\item (10 points) \textbf{Cryptocurrency Signature Scheme Analysis}
A new cryptocurrency project is choosing between ECDSA and Ed25519 for transaction signatures. The system requirements include:
\begin{itemize}
\item High transaction throughput (thousands of signatures per second)
\item Long-term security (system should remain secure for decades)
\item Compatibility with hardware wallets and mobile devices
\item Deterministic transaction signing for reproducibility
\end{itemize}
Analyze this decision:
\begin{enumerate}
\item Compare ECDSA and Ed25519 for each requirement above. Which algorithm better meets each criterion and why?
\item Discuss the implications of signature malleability. How does this affect each algorithm and why might it matter for cryptocurrency applications?
\item Analyze the quantum resistance of both options. What migration path would you recommend for long-term security?
\item Consider the ecosystem effects: existing wallet software, hardware support, and developer familiarity. How do these practical factors influence the decision?
\item Make a final recommendation with justification, considering both technical and practical factors.
\end{enumerate}
\item (10 points) \textbf{Secure Communication System Architecture}
You are architecting a secure communication system for a large organization (10,000+ employees) that needs to protect against both external attackers and potential insider threats. The system must support real-time messaging, file sharing, and voice calls.
Design and analyze a complete solution:
\begin{enumerate}
\item Specify your cryptographic algorithm choices for:
\begin{itemize}
\item Key exchange protocols
\item Digital signature schemes
\item Symmetric encryption algorithms
\item Hash functions and MACs
\end{itemize}
\item Describe your key management architecture. How do you bootstrap trust, distribute keys, and handle key rotation?
\item Analyze your system's security properties against various attack scenarios:
\begin{itemize}
\item Network eavesdropping
\item Server compromise
\item Endpoint compromise
\item Insider attacks
\end{itemize}
\item Discuss the performance implications of your design choices and how you would optimize for a large-scale deployment.
\item Evaluate your system's compliance with modern security standards and its readiness for post-quantum cryptography migration.
\end{enumerate}
\end{enumerate}
\begin{tcolorbox}[colframe=EarthBrown!30!white,colback=EarthBrown!5!white]
\textbf{Bonus Challenge (20 extra points):} The transition to post-quantum cryptography will require replacing current elliptic curve systems with quantum-resistant alternatives. Research and analyze one of the following aspects of this transition:
\begin{enumerate}
\item \textbf{NIST Post-Quantum Standards}: Analyze the recently standardized ML-KEM and ML-DSA algorithms. How do their key sizes, performance characteristics, and security assumptions compare to current ECC systems?
\item \textbf{Hybrid Classical/Post-Quantum Systems}: Describe approaches for combining classical and post-quantum algorithms during the transition period. What are the benefits and challenges of hybrid systems?
\item \textbf{Migration Timeline and Challenges}: Analyze the practical challenges of migrating existing systems (browsers, mobile apps, IoT devices) from ECC to post-quantum cryptography. What factors determine the migration timeline?
\end{enumerate}
Your answer should include: current standardization status, performance comparisons with existing systems, deployment challenges, and recommendations for practitioners preparing for the post-quantum transition. Check the Optional Readings under the topic listing for the Post-Quantum Cryptography on the course website for helpful references!
\end{tcolorbox}
\end{document}

BIN
misc/fonts/InriaSans-Bold.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/InriaSans-BoldItalic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/InriaSans-Italic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/InriaSans-Regular.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/JetBrainsMono-Bold.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/JetBrainsMono-BoldItalic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/JetBrainsMono-Italic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/JetBrainsMono-Regular.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/STIXTwoMath-Regular.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/STIXTwoText-Bold.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/STIXTwoText-BoldItalic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/STIXTwoText-Italic.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
misc/fonts/STIXTwoText-Regular.ttf (Stored with Git LFS) Normal file
View file

Binary file not shown.

8
misc/fonts/fonts.sty Normal file
View file

@ -0,0 +1,8 @@
\RequirePackage[T1]{fontenc}
\RequirePackage[utf8]{inputenc}
\RequirePackage{fontspec}
\RequirePackage{unicode-math}
\setsansfont[Scale=1.0]{Inria Sans}
\setmonofont[Scale=0.9]{JetBrains Mono}
\setromanfont[Scale=1.0]{STIX Two Text}
\setmathfont[Scale=1.0]{STIX Two Math}

61
misc/macros/classhandout.sty Normal file
View file

@ -0,0 +1,61 @@
\usepackage[pdftitle=Applied Cryptography,pdflang=en-US,colorlinks=true,linkcolor=OliveGreen,urlcolor=OliveGreen,citecolor=OliveGreen,bookmarksopen=true]{hyperref}
\usepackage{xurl,hyperxmp,graphicx,array,fancyhdr,bbding,pmboxdraw,listings,acronym,amsthm,bookmark,zref-totpages,xcolor,tikz,titlesec,enumitem,amsmath}
\usepackage[inner=2.50cm,outer=2.50cm,top=2.50cm,bottom=2.50cm]{geometry}
\usepackage{microtype}
\renewcommand{\familydefault}{\sfdefault}
\definecolor{OliveGreen}{HTML}{3F7E31}
\definecolor{EarthBrown}{HTML}{7D4C31}
\definecolor{LightestGray}{HTML}{EEEEEE}
\definecolor{DarkGray}{HTML}{5F6368}
\titleformat{\section}
{\normalfont\Large\bfseries\color{OliveGreen}}
{\thesection}{1em}{}
\titleformat{\subsection}
{\normalfont\large\bfseries\color{EarthBrown}}
{\thesubsection}{1em}{}
\pagestyle{fancy}
\fancyhf{}
\renewcommand{\headrulewidth}{0.3pt}
\renewcommand{\footrulewidth}{0.3pt}
\lhead{\textcolor{OliveGreen}{Applied Cryptography}}
\rhead{\textcolor{DarkGray}{American University of Beirut}}
\lfoot{\textcolor{DarkGray}{CMPS 297AD/396AI, Fall 2025}}
\rfoot{\textcolor{DarkGray}{Page \thepage\ of \ztotpages}}
\tcbsetforeverylayer{colframe=OliveGreen!20!white,colback=LightestGray,boxrule=0.5pt,arc=2mm,boxsep=5pt,left=6pt,right=6pt,top=6pt,bottom=6pt}
\thispagestyle{empty}
\setlist{itemsep=0em}
\newcommand{\classhandoutheader}{
\begin{tikzpicture}[remember picture, overlay]
\fill[OliveGreen!10!white] (current page.north west) rectangle ([yshift=-5cm]current page.north east);
\end{tikzpicture}
\vspace*{-1.5cm}
\noindent
\begin{minipage}[c]{0.35\textwidth}
\centering
\includegraphics[width=2.5in]{\aublogopath}
\end{minipage}
\begin{minipage}[c]{0.65\textwidth}
\begin{flushright}
\vspace{0.3cm}
{\fontsize{24}{28}\selectfont\textcolor{OliveGreen}{Applied Cryptography}}
\vspace{0.2cm}
{\large\textcolor{DarkGray}{CMPS 297AD/396AI, Fall 2025}}
\vspace{0.2cm}
\end{flushright}
\end{minipage}
\vspace{0.8cm}
\begin{tcolorbox}[colframe=OliveGreen!70!white,colback=white,arc=1mm]
\begin{center}
\begin{tabular}{ll}
\textbf{Instructor:} Nadim Kobeissi \quad\quad\quad\quad\quad \textbf{Website:} \url{https://appliedcryptography.page}
\end{tabular}
\end{center}
\end{tcolorbox}
\setlength{\unitlength}{1in}
\renewcommand{\arraystretch}{1.5}
}

98
misc/macros/joc.sty Normal file
View file

@ -0,0 +1,98 @@
\ProvidesPackage{joc}[2025/05/04 v1.0 Nadim's Joy of Cryptography Style Macros]
\RequirePackage{xcolor}
\RequirePackage[auto]{contour}
\RequirePackage{varwidth,tikz}
\RequirePackage[most]{tcolorbox}
\usetikzlibrary{shadows, arrows.meta, positioning, shapes, calc, fit, shapes.geometric}
\definecolor{jocbitcolor}{HTML}{A91716}
\definecolor{joctitlecolor}{HTML}{E5E5E5}
% Macro for state-separable proof style subroutines
\newcommand{\sssubroutine}[4]{
\begin{center}
\begin{tikzpicture}[box/.style={rectangle, draw, align=left, fill=white, inner sep=7pt, scale=#4, execute at begin node=\setlength{\baselineskip}{1.5em}}]
\node[box]{
\underline{\func{#1}{#2}}: \\
#3
};
\end{tikzpicture}
\end{center}
}
\newcommand{\sslibrarysubroutine}[4]{
\begin{tikzpicture}[box/.style={rectangle, align=left, inner sep=0pt, outer sep=0pt, fill=white, scale=#4, execute at begin node=\setlength{\baselineskip}{1.5em}, inner sep=0pt, outer sep=0pt}]
\node[box]{
\underline{\func{#1}{#2}}: \\
#3
};
\end{tikzpicture}
}
\newcommand{\prob}[1]{\ensuremath{\Pr\bigl[\ensuremath{#1}\bigr]}}
\newcommand{\lib}[2]{\ensuremath{\mathcal{L}^{#1}_\text{#2}}}
\newcommand{\prog}[1]{\ensuremath{\mathcal{A}_\text{#1}}}
\newcommand{\link}{\ensuremath{\diamond}}
\newcommand{\interchangeable}[1]{\ensuremath{\overset{\ensuremath{#1}}{\equiv}}}
\newcommand{\bit}[1]{\textcolor{jocbitcolor}{\texttt{#1}}}
\newcommand{\bits}{\ensuremath{\{\bit{0}, \bit{1}\}}}
\newcommand{\func}[2]{\ensuremath{\textrm{\textsc{#1}}\scalebox{1.05}{\ensuremath{(#2)}}}}
\newtcolorbox{sslibrarybox}[2][]{
colback=white,
colframe=black,
colbacktitle=joctitlecolor,
coltitle=black,
enhanced,hbox,
toptitle=1mm,
bottomtitle=1mm,
boxrule=0.5pt,
titlerule=0pt,
left=1mm,
right=1mm,
top=2mm,
bottom=2mm,
titlerule style=joctitlecolor,
sharp corners,
halign title=center,
title={#2},
#1
}
\newcommand{\sslibrary}[4]{
\begin{sslibrarybox}[scale=#4]{\lib{#1}{#2}}
\begin{varwidth}{\textwidth}
#3
\end{varwidth}
\end{sslibrarybox}
}
\newcommand{\ssprogram}[3]{
\begin{sslibrarybox}[scale=#3]{\prog{#1}}
\begin{tikzpicture}[box/.style={rectangle, align=left, fill=white, inner sep=0pt, outer sep=0pt, execute at begin node=\setlength{\baselineskip}{1.5em}}]
\node[box]{
#2
};
\end{tikzpicture}
\end{sslibrarybox}
}
\newcommand{\sslinked}[3]{
\begin{tikzpicture}[baseline]
\node[inner sep=0pt, outer sep=0pt] (left) {\begin{varwidth}{\textwidth}#1\end{varwidth}};
\node[inner sep=0pt, outer sep=0pt, anchor=west] (middle) at (left.east) {\begin{varwidth}{\textwidth}{\large\ensuremath{\ #2\ }}\end{varwidth}};
\node[inner sep=0pt, outer sep=0pt, anchor=west] (right) at (middle.east) {\begin{varwidth}{\textwidth}#3\end{varwidth}};
\end{tikzpicture}
}
\contourlength{1.2pt}
\newcommand{\hl}[1]{%
\relax\ifmmode%
{}%
\contour{hlbg}{\textcolor{hlfg}{${} #1 {}$}}%
{}%
\else%
\contour{hlbg}{\textcolor{hlfg}{#1}}%
\fi%
}

4173
misc/macros/msc5.sty Normal file
View file

File diff suppressed because it is too large Load diff

806
slides/1-1.tex Normal file
View file

@ -0,0 +1,806 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 1: Provable Security}
\covertopicname{1.1: Introduction}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Defining cryptography}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\definitionbox{What is Cryptography?}{\textit{``The science of enabling secure and private computation, communication, verification, and delegation in the presence of untrusted parties, adversarial behavior, and mutually distrustful participants.''}}
\end{column}
\begin{column}{0.5\textwidth}
\imagewithcaption{caesar.png}{Source: Serious Cryptography, 2nd Edition}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Defining cryptography}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\definitionbox{What is Cryptography?}{\textit{``The science of enabling secure and private computation, communication, verification, and delegation in the presence of untrusted parties, adversarial behavior, and mutually distrustful participants.''}}
\end{column}
\begin{column}{0.5\textwidth}
\imagewithcaption{vigenere.png}{Source: Serious Cryptography, 2nd Edition}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Cryptography is everywhere}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item Banking
\item Buying stuff from the store
\item Any digital payment system
\item Messaging (WhatsApp, Signal, iMessage, Telegram)
\item Voice calls
\item Government and military systems
\item SSH
\item VPN access
\item Visiting most websites (HTTPS)
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item Disk encryption
\item Cloud storage
\item Video conferencing
\item Unlocking your (newer) car
\item Identity card systems
\item Ticketing systems
\item DRM solutions
\item Private contact discovery
\item Cryptocurrencies
\item That iPhotos feature that detects similar photos
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{How it's made}
\bigimagewithcaption{fischer.png}{Fischer et al., The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts, USENIX Security 2024}
\end{frame}
\begin{frame}{How it's made}
\begin{center}
\bigimagewithcaption{fischer_sectioned.png}{Fischer et al., The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts, USENIX Security 2024}
\end{center}
\end{frame}
\begin{frame}{Cryptographic building blocks}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\textbf{Components}
\begin{itemize}[<+->]
\item Cryptography manifests as a set of primitives, from which we
build protocols intended to accomplish well-defined security goals.
\item \textbf{Primitives}: AES, RSA, SHA-2, DH\ldots
\item \textbf{Protocols}: TLS, Signal, SSH, FileVault 2, BitLocker\ldots
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\textbf{Examples}
\begin{itemize}[<+->]
\item \textbf{AES}: Symmetric encryption
\begin{itemize}
\item $\mathsf{Enc}(k, m) = c$, $\mathsf{Dec}(k, c) = m$.
\end{itemize}
\item \textbf{SHA-2}: Hash function
\begin{itemize}
\item $\mathsf{H}(m) = h$.
\end{itemize}
\item \textbf{Diffie-Hellman}: Public key agreement
\begin{itemize}
\item Allows two parties to agree on a secret key $k$.
\end{itemize}
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Cryptographic building blocks}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\textbf{Security goals}
\begin{itemize}[<+->]
\item \textbf{Confidentiality}: Data exchanged between Client and Server
is only known to those parties.
\item \textbf{Authentication}: If Server receives data from Client,
then Client sent it to Server.
\item \textbf{Integrity}: If Server modifies data owned by Client,
Client can find out.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\textbf{Examples}
\begin{itemize}[<+->]
\item \textbf{Confidentiality}: When you send a private message on Signal,
only you and the recipient can read the content.
\item \textbf{Authentication}: When you receive an email from your boss,
you can verify it actually came from them.
\item \textbf{Integrity}: Your computer can verify that software update
downloads haven't been tampered with during transmission.
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Security goals: more examples}
\begin{itemize}[<+->]
\item \textbf{TLS (HTTPS)} ensures that data exchanged between the client
and the server is confidential and that parties are authenticated.
\begin{itemize}
\item Allows you to log into gmail.com without your ISP learning your password.
\end{itemize}
\item \textbf{FileVault 2} ensures data confidentiality and integrity on
your MacBook.
\begin{itemize}
\item Prevents thieves from accessing your data if your MacBook is stolen.
\end{itemize}
\item \textbf{Signal} implements post-compromise security, an advanced security
goal.
\begin{itemize}
\item Allows a conversation to ``heal'' in the event of a temporary key
compromise.
\item More on that later in the course.
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Why bother?}
\begin{itemize}[<+->]
\item Can't we just use access control?
\item Strictly speaking, usernames and passwords can be implemented
without cryptography\ldots
\item Server checks if the password matches, or if the IP address matches,
etc. before granting access.
\item What's so bad about that?
\end{itemize}
\definitionbox{The Problem with Traditional Access Control}{
\begin{itemize}[<+->]
\item Requires trusting the server completely
\item No protection during transmission
\item No way to verify integrity
\item No way to establish trust between strangers
\end{itemize}
}
\end{frame}
\begin{frame}[c]{The magic of cryptography}
\begin{center}
\Large\textbf{Cryptography lets us achieve what seems impossible}
\vspace{1cm}
\begin{itemize}[<+->]
\item Secure communication over insecure channels
\item Verification without revealing secrets
\item Proof of computation without redoing it
\end{itemize}
\end{center}
\end{frame}
\begin{frame}{Hard problems}
\begin{itemize}[<+->]
\item Cryptography is largely about equating the security of a system to the
difficulty of solving a math problem that is thought to be computationally
very expensive.
\item With cryptography, we get security systems that we can literally
mathematically prove as secure (under assumptions).
\item Also, this allows for actual magic.
\begin{itemize}[<+->]
\item Alice and Bob meet for the first time in the same room as you.
\item You are listening to everything they are saying.
\item Can they exchange a secret without you learning it?
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Time for actual magic}
\bigimagewithcaption{dh.png}{}
\end{frame}
\begin{frame}{No known feasible computation}
\begin{itemize}[<+->]
\item The discrete logarithm problem:
\begin{itemize}
\item Given a finite cyclic group $G$, a generator $g \in G$, and an element
$h \in G$, find the integer $x$ such that $g^{x}=h$
\end{itemize}
\item In more concrete terms:
\begin{itemize}
\item Let $p$ be a large prime and let $g$ be a generator of the multiplicative
group $\mathbb{Z}_{p}^{*}$ (all nonzero integers modulo $p$).
\item Given:
\begin{itemize}
\item $g \in \mathbb{Z}_{p}^{*}$, $h \in \mathbb{Z}_{p}^{*}$
\item Find $x \in \{0, 1, \ldots, p-2\}$ such that $g^{x} \equiv h \pmod
{p}$
\end{itemize}
\item This problem is believed to be computationally hard when $p$ is large
and $g$ is a primitive root modulo $p$.
\begin{itemize}
\item ``Believed to be'' = we don't know of any way to do it that doesn't
take forever, unless we have a strong, stable quantum computer (Shor's
algorithm)
\end{itemize}
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Hard problems}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\textbf{Asymmetric Primitives}
\begin{itemize}[<+->]
\item Diffie-Hellman, RSA, ML-KEM, etc.
\item ``Asymmetric'' because there is a ``public key'' and a ``private
key'' for each party.
\item Algebraic, assume the hardness of mathematical problems (as seen
just now.)
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\textbf{Symmetric Primitives}
\begin{itemize}[<+->]
\item AES, SHA-2, ChaCha20, HMAC\ldots
\item ``Symmetric'' because there is one secret key.
\item Not algebraic but unstructured, but on their understood
resistance to $n$ years of cryptanalysis.
\item Can act as substitutes for assumptions in security proofs!
\begin{itemize}
\item Example: hash function assumed to be a ``random oracle''
\end{itemize}
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Kerckhoff's principle}
\begin{itemize}[<+->]
\item \textit{``A cryptosystem should be secure even if everything about
the system, except the key, is public knowledge.''} — Auguste Kerckhoffs,
1883
\item \textbf{Why it matters}:
\begin{itemize}[<+->]
\item No ``security through obscurity''
\item The key is the only secret: the rest can be audited, tested,
trusted
\item Encourages open standards and peer review
\item If your system's security depends on nobody knowing how it works,
it's not secure.
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Symmetric primitive example: hash functions}
\begin{columns}[c]
\begin{column}{0.55\textwidth}
\definitionbox{Hash Function Properties}{
\begin{itemize}\item Takes input of \textbf{any size}[<+->]
\item Produces output of \textbf{fixed size}
\item Is \textbf{deterministic} (same input $\rightarrow$ same output)
\item Even a \textbf{tiny change} in input creates completely different output
\item Is \textbf{efficient} to compute\end{itemize}
}
\end{column}
\begin{column}{0.45\textwidth}
\begin{tcolorbox}
[colback=black!5!white,colframe=ciphergray] $\mathsf{SHA256}(\texttt{hello}) =$ \\ \texttt{2cf24dba5fb0a30e26e83b2ac5}\\ \texttt{b9e29e1b161e5c1fa7425e7304}\\
\texttt{3362938b9824}
$\mathsf{SHA256}(\texttt{hullo}) =$ \\ \texttt{7835066a1457504217688c8f5d}\\
\texttt{06909c6591e0ca78c254ccf174}\\ \texttt{50d0d999cab0}
\end{tcolorbox}
\textcolor{cipherprimary}{\textbf{Note:} \small One character change $\rightarrow$
completely different hash!}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Expected properties of a hash function}
\begin{columns}[c]
\begin{column}{0.6\textwidth}
\begin{itemize}[<+->]
\item \textbf{Collision resistance}: computationally infeasible to find
two different inputs producing the same hash.
\item \textbf{Preimage resistance}: given the output of a hash function,
it is computationally infeasible to reconstruct the original input.
\item \textbf{Second preimage resistance}: given an input and an output,
it's computationally infeasible to find another different input
producing the same output.
\end{itemize}
\end{column}
\begin{column}{0.4\textwidth}
\imagewithcaption{sha2.png}{SHA-2 compression function. Source: Wikipedia}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Hash functions: what are they good for?}
\begin{itemize}[<+->]
\item \textbf{Password storage}: Store the hash of the password on the server,
not the password itself. Then check candidate passwords against the hash.
\item \textbf{Data integrity verification}: Hash a file. Later hash it
again and compare hashes to check if the file has changed, suffered storage
degradation, etc.
\item \textbf{Proof of work}: Server asks client to hash something a lot of
times before they can access some resource. Useful for anti-spam, Bitcoin
mining, etc.
\item \textbf{Zero knowledge proofs}: time for more actual magic
\end{itemize}
\end{frame}
\begin{frame}{Time for more actual magic}
\begin{columns}[c]
\begin{column}{0.6\textwidth}
\begin{itemize}[<+->]
\item \textbf{Zero-knowledge proofs} allow you to prove that you know
a secret without revealing any information about it.
\item They built ``zero-knowledge virtual machines'' where you can execute
an entire program that runs as a zero-knowledge proof.
\item ZKP battleship game: server proves to the players that its
output to their battleship guesses is correct, without revealing any
additional information (e.g. ship location).
\end{itemize}
\end{column}
\begin{column}{0.4\textwidth}
\imagewithcaption{battleship.jpg}{Battleship board game. Source: Hasbro}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Evaluating a hash function's quality}
\begin{columns}[c]
\begin{column}{0.6\textwidth}
\begin{itemize}[<+->]
\item \textbf{Recall}:
\begin{itemize}[<+->]
\item \textbf{Asymmetric primitives} are based on mathematical
problems, can be mathematically proven secure (given assumptions!)
\item \textbf{Symmetric primitives} (encryption, hashing\ldots)
are statistically, empirically, heuristically shown to be secure,
not proven secure.
\item The more cryptanalysis they survive, the higher confidence
we have in their security.
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.4\textwidth}
\imagewithcaption{qiao.png}{Cryptanalysis of AES.}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{What about encryption?}
\begin{columns}[c]
\begin{column}{0.6\textwidth}
\begin{itemize}[<+->]
\item Symmetric primitive of choice for encryption: \textbf{AES}.
\item Not that far off in terms of design process from hash functions,
but:
\begin{itemize}[<+->]
\item AES is a PRP (pseudorandom permutation)
\item HMAC-SHA256 is a PRF (pseudorandom function)
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.4\textwidth}
\imagewithcaption{aes_subbytes.png}{AES's SubBytes operation. Source: Wikipedia}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{PRF versus PRP}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\textbf{Pseudo-Random Function (SHA-2)}
\begin{itemize}[<+->]
\item \textbf{Input} is arbitrary-length,
\item \textbf{Output} is fixed-length, looks random (as discussed
earlier).
\item Indistinguishable from a truly random function by an adversary with
limited computational power.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\textbf{Pseudo-Random Permutation (AES)}
\begin{itemize}[<+->]
\item \textbf{Input and output} are the same length, forming a permutation.
\item Each input maps uniquely to one output, allowing invertibility.
\item Indistinguishable from a truly random permutation by an adversary
with limited computational power.
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{$\mathsf{PRF}: F_{k}= X \rightarrow Y$}
\begin{columns}[c]
\begin{column}{0.4\textwidth}
\begin{itemize}
\item We want the mapping to be:
\begin{itemize}
\item One-way
\item ``Randomized''
\item Relations between inputs not reflected in outputs
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.8\textwidth}
\begin{tikzpicture}[scale=0.38]
% Define colors
\definecolor{domaingreen}{RGB}{102, 170, 68}
\definecolor{rangegreen}{RGB}{170, 187, 136}
\definecolor{circlecolor}{RGB}{235, 137, 85}
\definecolor{purplearrow}{RGB}{160, 78, 160}
\definecolor{redarrow}{RGB}{237, 50, 36}
% Input space (domain) X - made square
\draw[dashed, thick, domaingreen, fill=domaingreen]
(0,0) rectangle (8,8);
\node[text width=6.5cm, align=center, font=\normalsize]
at
(4,-0.8)
{Size: infinite!};
\node[font=\small] at (4,9) {Input space (domain) $X$};
% Output (range) Y - made square - moved more to the right
\draw[thick, rangegreen, fill=rangegreen] (15,2) rectangle (20,7);
\node[text width=4cm, align=center, font=\normalsize]
at
(17.5,1.2)
{Size: fixed};
\node[font=\small] at (17.5,8.5) {Output (range) $Y$};
% Input dots - adjusted positions for square domain
\filldraw[circlecolor] (2,7) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,7) -- (16.2,6.4);
\pause
\filldraw[circlecolor] (16.2,6.4) circle (0.3);
\pause
\filldraw[circlecolor] (3,6) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(3,6) -- (18.6,5.3);
\pause
\filldraw[circlecolor] (18.6,5.3) circle (0.3);
\pause
\filldraw[circlecolor] (2,5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,5) -- (16.8,4.2);
\pause
\filldraw[circlecolor] (16.8,4.2) circle (0.3);
\pause
\filldraw[circlecolor] (4,3.5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(4,3.5) -- (18.4,3.2);
\pause
\filldraw[circlecolor] (18.4,3.2) circle (0.3);
\pause
\filldraw[circlecolor] (2,2) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,2) -- (17.1,2.7);
\pause
\filldraw[circlecolor] (17.1,2.7) circle (0.3);
\pause
\filldraw[circlecolor] (3,1) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, ultra thick, redarrow]
(3,1) -- (16.8,4.2);
\node[redarrow, font=\scriptsize\bfseries, rotate=14]
at
(10,3)
{Collisions are inevitable};
\end{tikzpicture}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{$\mathsf{PRP}: F_{k}= X \rightarrow X$}
\begin{columns}[c]
\begin{column}{0.4\textwidth}
\begin{itemize}
\item \textbf{Bijective} (two-way)
\begin{itemize}
\item \textbf{Injective}: no two inputs map to same output (no
collisions)
\item \textbf{Surjective}: Every output has one corresponding input
\end{itemize}
\item ``Randomized''
\item Relations between inputs not reflected in outputs
\end{itemize}
\end{column}
\begin{column}{0.8\textwidth}
\begin{tikzpicture}[scale=0.38]
% Define colors
\definecolor{domaingreen}{RGB}{102, 170, 68}
\definecolor{rangegreen}{RGB}{102, 170, 68}
\definecolor{circlecolor}{RGB}{235, 137, 85}
\definecolor{purplearrow}{RGB}{160, 78, 160}
% Input space (domain) X - made square
\draw[dashed, thick, domaingreen, fill=domaingreen]
(0,0) rectangle (8,8);
\node[text width=6.5cm, align=center, font=\normalsize]
at
(4,-0.8)
{Size: fixed};
\node[font=\normalsize] at (4,9) {Input space (domain) $X$};
% Output (range) Y - made square, same size as domain, moved left
\draw[thick, rangegreen, fill=rangegreen] (12,0) rectangle (20,8);
\node[text width=6.5cm, align=center, font=\normalsize]
at
(16,-0.8)
{Size: fixed};
\node[font=\normalsize] at (16,9) {Output (range) $X$};
% Input dots - adjusted positions for square domain
\filldraw[circlecolor] (2,7) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,7) -- (14.2,7.4);
\pause
\filldraw[circlecolor] (14.2,7.4) circle (0.3);
\pause
\filldraw[circlecolor] (3,6) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(3,6) -- (18.6,5.3);
\pause
\filldraw[circlecolor] (18.6,5.3) circle (0.3);
\pause
\filldraw[circlecolor] (2,5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,5) -- (13.8,4.2);
\pause
\filldraw[circlecolor] (13.8,4.2) circle (0.3);
\pause
\filldraw[circlecolor] (4,3.5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(4,3.5) -- (17.4,2.2);
\pause
\filldraw[circlecolor] (17.4,2.2) circle (0.3);
\pause
\filldraw[circlecolor] (2,2) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,2) -- (16.1,6.7);
\pause
\filldraw[circlecolor] (16.1,6.7) circle (0.3);
\pause
\filldraw[circlecolor] (3,1) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(3,1) -- (19.0,1.4);
\pause
\filldraw[circlecolor] (19.0,1.4) circle (0.3);
\end{tikzpicture}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{AES is a block cipher}
\begin{itemize}[<+->]
\item AES takes a 16-byte input, produces a 16-byte output.
\item Key can be 16, 24 or 32 bytes.
\item OK, so what if we want to encrypt more than 16 bytes?
\item \textbf{Proposal}: split the plaintext into 16 byte chunks, encrypt
each of them with the same key.
\end{itemize}
\end{frame}
\begin{frame}{Block cipher examples}
\begin{columns}
\begin{column}{0.33\textwidth}
\imagewithcaption{tux_plaintext.png}{What we start with}
\end{column}
\pause
\begin{column}{0.33\textwidth}
\imagewithcaption{tux_encrypted_ecb.png}{What we get}
\end{column}
\pause
\begin{column}{0.33\textwidth}
\imagewithcaption{tux_encrypted_ctr.png}{What we actually want}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Block cipher modes of operation}
\bigimagewithcaption{block_cipher_modes.png}{Source: Wikipedia}
\end{frame}
\begin{frame}{Cryptographic building blocks}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\textbf{Security goals}
\begin{itemize}
\item \textbf{Confidentiality}: Data exchanged between Client and Server
is only known to those parties.
\item \textbf{Authentication}: If Server receives data from Client,
then Client sent it to Server.
\item \textbf{Integrity}: If Server modifies data owned by Client,
Client can find out.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\textbf{Examples}
\begin{itemize}[<+->]
\item \textbf{Confidentiality}: When you send a private message on Signal,
only you and the recipient can read the content.
\item \textbf{Authentication}: When you receive an email from your boss,
you can verify it actually came from them.
\item \textbf{Integrity}: Your computer can verify that software update
downloads haven't been tampered with during transmission.
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Security goals: more examples}
\begin{itemize}[<+->]
\item \textbf{TLS (HTTPS)} ensures that data exchanged between the client
and the server is confidential and that parties are authenticated.
\begin{itemize}
\item Allows you to log into gmail.com without your ISP learning your password.
\end{itemize}
\item \textbf{FileVault 2} ensures data confidentiality and integrity on
your MacBook.
\begin{itemize}
\item Prevents thieves from accessing your data if your MacBook is stolen.
\end{itemize}
\item \textbf{Signal} implements post-compromise security, an advanced security
goal.
\begin{itemize}
\item Allows a conversation to ``heal'' in the event of a temporary key
compromise.
\item More on that later in the course.
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{TLS 1.3: high-level sketch}
\bigimagewithcaption{tls_13_sketch}{Source: Mostafa Ibrahim}
\end{frame}
\begin{frame}{TLS 1.3: high-level sketch}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item \textbf{Public key agreement} (eg. Diffie-Hellman) is used to establish
a shared secret between the client and the server.
\item \textbf{AES} is used for encrypting data in transit.
\item \textbf{SHA-2} is used for hashing (checking certificates, etc.)
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\bigimagewithcaption{tls_13_sketch}{Source: Mostafa Ibrahim}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{TLS 1.3: high-level sketch}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item Through the design, we accomplish the desired \textbf{security
goals} under a well-specified \textbf{threat model}:
\item \textbf{Security goals}: confidentiality of data, authentication
of the server towards the client\ldots
\item \textbf{Threat model}: malicious Internet Service Provider (ISP),
etc.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\bigimagewithcaption{tls_13_sketch}{Source: Mostafa Ibrahim}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{How TLS 1.3 was made}
\bigimagewithcaption{fischer}{}
\end{frame}
\begin{frame}{How TLS 1.3 was made}
\bigimagewithcaption{fischer_tls_13_bubbles}{}
\end{frame}
\begin{frame}{From hard problems to real-world security}
\begin{center}
\Large\textbf{The journey we'll trace}
\end{center}
\vspace{0.5cm}
\begin{enumerate}[<+->]
\item \textbf{Mathematical insight}: Discrete logarithm is hard to compute.
\item \textbf{Cryptographic innovation}: Diffie-Hellman key exchange leverages this hardness.
\item \textbf{Real-world impact}: Secure communication for billions of people daily.
\end{enumerate}
\vspace{1cm}
\textbf{This is the power of applied cryptography}: transforming abstract mathematical problems into tools that help people and protect our digital lives.
\end{frame}
\begin{frame}{Course goals}
\begin{itemize}[<+->]
\item Understand the reasoning behind the math of modern cryptography.
\item Analyze and prove the security of cryptographic constructions.
\item Understand how cryptographic constructions can be composed to build real-world
secure protocols and systems.
\item Discern between theoretical cryptography and applied cryptography from
an engineering perspective.
\item Critically assess security implementations and evaluate real-world cryptographic
protocols.
\item Gain an understanding of the future of cryptography and its role in emerging
technologies.
\end{itemize}
\end{frame}
\begin{frame}{Course prerequisites}
\begin{itemize}
\item Good but optional: CMPS 215 (Theory of Computation)
\item If you want to understand whether you have the sufficient background for this course, review this revision chapter and try to do all the exercises: \url{https://joyofcryptography.com/pdf/chap0.pdf}
\end{itemize}
\end{frame}
\begin{frame}{Class materials}
\begin{itemize}[<+->]
\item \textbf{Joy of Cryptography}: learn how to reason about and prove systems secure.
\item \textbf{Attack papers, codebases, labs}: hard engineering perspective.
\vspace{1cm}
\item \textbf{Always keep an eye on the website:} Course news, updates,
materials, slides will all be posted there.
\url{https://appliedcryptography.page}
\item I am aiming for the most engaging course possible!
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

500
slides/1-2.tex Normal file
View file

@ -0,0 +1,500 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 1: Provable Security}
\covertopicname{1.2: One-Time Pad \& The Provable Security Mindset}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{How it's made}
\bigimagewithcaption{fischer_theory.png}{Fischer et al., The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts, USENIX Security 2024}
\end{frame}
\begin{frame}{Thinking about secrecy}
\bigimagewithcaption{naive_enc.pdf}{Source: The Joy of Cryptography}
\end{frame}
\begin{frame}{Thinking about secrecy}
\begin{columns}[c]
\column{0.5\textwidth}{
\begin{itemize}[<+->]
\item Keep the whole design secret?
\item \textbf{``Advantages''}:
\begin{itemize}[<+->]
\item Attacker doesn’t know how our cipher (or system, more generally,) works.
\end{itemize}
\item \textbf{Disadvantages}:
\begin{itemize}[<+->]
\item Figuring out how the thing works might mean a break.
\item Can’t expose cipher to scrutiny.
\item Everyone needs to invent a cipher.
\end{itemize}
\end{itemize}
}
\column{0.5\textwidth}{
\imagewithcaption{naive_enc.pdf}{Source: The Joy of Cryptography}
}
\end{columns}
\end{frame}
\begin{frame}{Kerckhoff's principle}
\begin{itemize}[<+->]
\item \textit{``A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.''} — Auguste Kerckhoffs, 1883
\item \textbf{Why it matters}:
\begin{itemize}[<+->]
\item No ``security through obscurity''
\item The key is the only secret: the rest can be audited, tested, trusted
\item Encourages open standards and peer review
\item If your system's security depends on nobody knowing how it works, it's not secure.
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Thinking about secrecy}
\bigimagewithcaption{keyed_enc.pdf}{\textbf{Concentrate all the need for secrecy in the key!}}
\end{frame}
\begin{frame}{Thinking about secrecy}
\begin{columns}[c]
\column{0.5\textwidth}{
\begin{itemize}[<+->]
\item Cipher can be scrutinized, used by anyone.
\item Design can be shown to hold so long as the key is secret.
\item This is how virtually all cryptography is designed today.
\end{itemize}
}
\column{0.5\textwidth}{
\imagewithcaption{keyed_enc.pdf}{Source: The Joy of Cryptography}
}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{First look at a symmetric cipher}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\sssubroutine{Enc}{K, M}{
$C \coloneq K \oplus M$ \\
return $C$
}{2}
\end{column}
\begin{column}{0.5\textwidth}
\sssubroutine{Dec}{K, C}{
$M \coloneq K \oplus C$ \\
return $M$
}{2}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{XOR (Exclusive OR) operation}
\begin{columns}[c]
\column{0.6\textwidth}{
\begin{table}
\centering
\begin{tabular}{|c|c|c|}
\hline
\textbf{A} & \textbf{B} & \textbf{A $\oplus$ B} \\
\hline
\texttt{0} & \texttt{0} & \texttt{0} \\
\hline
\texttt{0} & \texttt{1} & \texttt{1} \\
\hline
\texttt{1} & \texttt{0} & \texttt{1} \\
\hline
\texttt{1} & \texttt{1} & \texttt{0} \\
\hline
\end{tabular}
\caption{Truth table for XOR operation}
\end{table}
\begin{itemize}
\item XOR returns 1 when inputs differ
\item XOR returns 0 when inputs are the same
\item Key property: $x \oplus x = 0$ and $x \oplus 0 = x$
\item Self-inverse: $(M \oplus K) \oplus K = M$
\end{itemize}
}
\column{0.4\textwidth}{
\begin{center}
\begin{tikzpicture}[scale=0.8]
\draw[thick] (0,0) circle (1.5);
\draw[thick] (1,0) circle (1.5);
\node at (0,-2) {A};
\node at (1,-2) {B};
\begin{scope}
\clip (0,0) circle (1.5);
\clip (1,0) circle (1.5);
\fill[cyan!30] (-1.5,-1.5) rectangle (2.5,1.5);
\end{scope}
\draw[thick] (0,0) circle (1.5);
\draw[thick] (1,0) circle (1.5);
\node at (0.5,0) {$A \oplus B$};
\end{tikzpicture}
\end{center}
}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{First look at a symmetric cipher}
\bigimagewithcaption{xor_enc.png}{(We're encoding the message and key as bits)}
\end{frame}
\begin{frame}{One-time pad}{First look at a symmetric cipher}
\bigimagewithcaption{xor_dec.png}{(We're encoding the message and key as bits)}
\end{frame}
\begin{frame}{Key derivation}{Uniform distribution}
\begin{itemize}[<+->]
\item How to derive $K$?
\item $K$ is ideally random.
\item True randomness isn’t practical, so $K$ is in practice pseudo-random.
\item We need a pseudo-random uniform distribution:
\item If $\mathcal{S}$ is a set of $m$ items, then the uniform distribution over $\mathcal{S}$ assigns probability $\frac{1}{m}$ to each item $x \in \mathcal{S}$
\item In practice, this just means we need the bits to be random, unpredictable, uniformly distributed in terms of probability
\item Sampling a $K$ from a pseudo-random uniform distribution is written as $K \twoheadleftarrow \bits^n$
\end{itemize}
\end{frame}
\begin{frame}{Adversary's access to oracle}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item ``Victim'' chooses their key.
\item Adversary chooses the message and receives the ciphertext.
\item We say that \textbf{the adversary has access to an encryption oracle}.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\imagewithcaption{attacker_interface.pdf}{Source: The Joy of Cryptography}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Adversary's access to oracle}
\begin{center}
\begin{tikzpicture}[
box/.style={rectangle, draw, minimum height=2.5cm, align=left, fill=white},
dashed box/.style={rectangle, draw, dashed, minimum width=2.5cm, minimum height=2.5cm, align=center, fill=white},
>=Stealth,
]
\node[dashed box] (adversary) {$adversary$};
\node[box, right=2cm of adversary](attack){
$\underline{\func{attack}{M}}$: \hfill \quad \quad \textcolor{gray}{\scriptsize \textit{// adversary chooses $M$}} \\
\quad $K \twoheadleftarrow \bits^{n}$ \hfill \quad \quad \textcolor{gray}{\scriptsize \textit{// victim samples $K$}} \\
\quad $C \coloneq \textsf{Enc}(K, M)$ \hfill \quad \quad \textcolor{gray}{\scriptsize \textit{// victim encrypts}} \\
\quad return $C$ \hfill \quad \quad \textcolor{gray}{\scriptsize \textit{// adversary sees $C$}}
};
\draw[->] (adversary) -- node[above] {$M$} (attack);
\draw[<-] ([yshift=-0.5cm]adversary.east) -- node[below] {$C$} ([yshift=-0.5cm]attack.west);
\end{tikzpicture}
\end{center}
\end{frame}
\begin{frame}{Adversary's access to oracle}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item Adversary can query oracle an unbounded number of times.
\item Two queries with same $M$ may return different $(C, C')$, since victim may use different $K$.
\item $K$ is always chosen correctly (pseudo-random uniform sampling)
\item ``Randomized oracle''
\item Attacker cannot see $K$.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\imagewithcaption{attacker_interface.pdf}{Source: The Joy of Cryptography}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Adversary's access to oracle}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}
\item When we prove security, we prove what is or isn’t possible by the attacker calling \textsc{Attack}$(M)$.
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\imagewithcaption{attacker_interface.pdf}{Source: The Joy of Cryptography}
\end{column}
\end{columns}
\end{frame}
\begin{frame}
\begin{center}
\Large\textit{``If I use OTP according to the attack scenario (I sample keys uniformly and use each key to encrypt just one ciphertext), then no matter how the plaintexts are chosen, and no matter how the ciphertext is subsequently used, I can enjoy a certain security guarantee.''}
\end{center}
\end{frame}
\begin{frame}{One-time pad}{Correctness proof}
\begin{itemize}[<+->]
\item $\forall(n > 0,\; K \in \bits^{n},\; M \in \bits^{n}),\; \textsf{Dec}(K, \textsf{Enc}(K, M)) = M$
\item For all positive $n$, any key of $n$ bits and message of $n$ bits will decrypt back to the same plaintext if encrypted into a ciphertext.
\item \textbf{Proof}:
\begin{align*}
\textsf{Dec}(K, \textsf{Enc}(K, M)) & = \textsf{Dec}(K, K \oplus M) \\
& = K \oplus (K \oplus M) \\
& = (K \oplus K) \oplus M \\
& = 0^n \oplus M \\
& = M \quad \qed
\end{align*}
\end{itemize}
\end{frame}
\begin{frame}{One-time pad}{How do we prove security?}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item \textbf{Generally}: a cipher is secure if the adversary can't distinguish the output of calls to $ATTACK$ from random junk.
\item \textbf{Formally}: For all positive integers $n$ and all choices of plaintext $M \in \{\texttt{0}, \texttt{1}\}^n$, the output of the following subroutine is uniformly distributed:
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \bits^{n}$ \\
$C \coloneq K \oplus M$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{How do we prove security?}
\begin{columns}[c]
\begin{column}{0.7\textwidth}
\begin{itemize}[<+->]
\item If the key is random, the output will be uniformly distributed!
\item Suppose $M = \bit{01}$:
\begin{itemize}[<+->]
\item $K = \bit{00}$ is chosen with probability $1/4$:\\$C = K \oplus M = \bit{00} \oplus \bit{01} = \bit{01}$.
\item $K = \bit{01}$ is chosen with probability $1/4$:\\$C = K \oplus M = \bit{01} \oplus \bit{01} = \bit{00}$.
\item $K = \bit{10}$ is chosen with probability $1/4$:\\$C = K \oplus M = \bit{10} \oplus \bit{01} = \bit{11}$.
\item $K = \bit{11}$ is chosen with probability $1/4$:\\$C = K \oplus M = \bit{11} \oplus \bit{01} = \bit{10}$.
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.3\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \bits^{n}$ \\
$C \coloneq K \oplus M$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{How do we prove security?}
\begin{columns}[c]
\begin{column}{0.7\textwidth}
\begin{itemize}[<+->]
\item What if this is true only for $M = \bit{01}$?
\item Fine, let's pick any $M, C \in \bits^n$.
\item What is \prob{\textsc{Attack}$(M) = C$}?
\item Answer: Exactly when $C = \textsf{Enc}(K, M) = K \oplus M$.
\item ...which occurs for exactly one $K$.
\item Since $K$ is chosen uniformly from $\bits^n$, the probability of choosing that $K$ is $\frac{1}{2^n}. \quad \qed$
\end{itemize}
\end{column}
\begin{column}{0.3\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \bits^{n}$ \\
$C \coloneq K \oplus M$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{From the adversary's perspective...}
\begin{columns}[c]
\begin{column}{0.35\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \bits^{n}$ \\
$C \coloneq K \oplus M$ \\
return $C$
}{1.5}
\end{column}
\begin{column}{0.3\textwidth}
\begin{center}
{\huge{$\approxeq$}} \\[1em]
{\scriptsize\textit{(indistinguishable \\ from)}}
\end{center}
\end{column}
\begin{column}{0.35\textwidth}
\sssubroutine{Junk}{M}{
$C \twoheadleftarrow \bits^{n}$ \\
return $C$
}{2}
\end{column}
\end{columns}
\end{frame}
\begin{frame}
\begin{center}
\huge \textit{``Real or random?''}
\end{center}
\end{frame}
\begin{frame}{Limitations of security proofs}{Part 1}
\begin{itemize}[<+->]
\item Rigor and the real world famously don't mix.
\item Security proofs are good for rigor but address very little regarding real-world concerns:
\begin{itemize}[<+->]
\item How can Alice \& Bob obtain a secret key, which only they know?
\item How can they keep $K$ secret?
\item How can a computer sample from the uniform distribution?
\item How can Alice ensure that $C$ is sent reliably to Bob?
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Limitations of security proofs}{Part 2}
\begin{itemize}[<+->]
\item More questions proofs don't address:
\begin{itemize}[<+->]
\item How can Alice hide the fact that she is talking to Bob (rather than hide only the content)?
\item How can Alice be sure that she is communicating with Bob, not an impostor?
\item How can we incentivize Alice and Bob to use encryption?
\item Should the government be allowed to obtain a warrant to read encrypted communications?
\end{itemize}
\item Security proofs are about specific properties within specific models.
\item Real-world security depends on many factors beyond what our models capture.
\item Having a security proof is necessary but not sufficient for real-world security.
\end{itemize}
\end{frame}
\begin{frame}{The value of security proofs}
\begin{itemize}[<+->]
\item Despite limitations, security proofs provide important benefits:
\begin{itemize}[<+->]
\item \textbf{Precise guarantees}: Clearly define what security properties are achieved.
\item \textbf{Confidence}: When properly structured, proofs ensure no obvious attacks exist.
\item \textbf{Foundation for composition}: Proven components can be securely combined.
\item \textbf{Precise terminology}: Forces us to clearly define our terms and assumptions.
\end{itemize}
\item Security proofs help identify the \textit{boundaries} of security:
\begin{itemize}[<+->]
\item What assumptions are necessary?
\item What threats are addressed vs. unaddressed?
\item What conditions must hold for security to be maintained?
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{The provable security mindset}
\begin{itemize}[<+->]
\item Building systems with provable security in mind:
\begin{itemize}[<+->]
\item Start with clear security goals and adversary model.
\item Design systems whose security can be formally analyzed.
\item Identify and document necessary assumptions.
\item Distinguish between proven properties and conjectures.
\end{itemize}
\item Good practical security requires both:
\begin{itemize}[<+->]
\item Rigorous proofs for core mechanisms.
\item Practical engineering to address real-world constraints.
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{OTP: security assumptions \& constraints}{Part 1}
\begin{itemize}[<+->]
\item Our security proofs rely on specific assumptions about the adversary:
\begin{itemize}[<+->]
\item \textbf{Key reuse}: Keys are never intentionally reused (though may repeat by chance).
\item \textbf{Observation only}: Adversary passively observes ciphertext but doesn't tam.per with it
\item \textbf{Message independence}: Choice of message $M$ is independent of key $K$.
\item \textbf{Key secrecy}: Adversary learns nothing about the key.
\item \textbf{No sampling influence}: Adversary cannot influence how the key is sampled.
\end{itemize}
\item These constraints are \textit{necessary} for the security proofs to hold!
\end{itemize}
\end{frame}
\begin{frame}{OTP: security assumptions \& constraints}{Part 2}
\begin{itemize}[<+->]
\item Side-channel attacks violate our model:
\begin{itemize}[<+->]
\item We assume adversary cannot coerce victim to run a different algorithm.
\item Cannot observe execution details:
\begin{itemize}[<+->]
\item CPU timing information (clock cycles).
\item Memory access patterns.
\item Cache hits/misses.
\item Power consumption during encryption.
\end{itemize}
\end{itemize}
\item Real-world security requires considering these additional attack vectors.
\item Our security proofs address a \textit{specific threat model} that may not capture all real-world threats.
\end{itemize}
\end{frame}
\begin{frame}{One-time pad}{What's so special about XOR?}
\begin{columns}[c]
\begin{column}{0.7\textwidth}
\begin{itemize}[<+->]
\item Let's replace $\oplus$ with $\land$. What would happen?
\item Output no longer uniform!
\end{itemize}
\begin{table}
\centering
\begin{tabular}{|c|c|c|}
\hline
\textbf{A} & \textbf{B} & \textbf{A $\land$ B} \\
\hline
\texttt{0} & \texttt{0} & \texttt{0} \\
\hline
\texttt{0} & \texttt{1} & \texttt{0} \\
\hline
\texttt{1} & \texttt{0} & \texttt{0} \\
\hline
\texttt{1} & \texttt{1} & \texttt{1} \\
\hline
\end{tabular}
\caption{Truth table for AND operation}
\end{table}
\end{column}
\begin{column}{0.3\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \bits^{n}$ \\
$C \coloneq K \land M$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{One-time pad}{What about $\%\ n$?}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item Let's replace $\oplus$ with $\%\ n$. What would happen?
\item Still good!
\item Can you prove correctness and security?
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\sssubroutine{Attack}{M}{
$K \twoheadleftarrow \mathbb{Z}_{n}$ \\
$C \coloneq (K + M)\ \%\ n$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

1279
slides/1-3.tex Normal file
View file

File diff suppressed because it is too large Load diff

2163
slides/1-4.tex Normal file
View file

File diff suppressed because it is too large Load diff

1657
slides/1-5.tex Normal file
View file

File diff suppressed because it is too large Load diff

1058
slides/1-6.tex Normal file
View file

File diff suppressed because it is too large Load diff

1415
slides/1-7.tex Normal file
View file

File diff suppressed because it is too large Load diff

1300
slides/1-8.tex Normal file
View file

File diff suppressed because it is too large Load diff

2633
slides/2-1.tex Normal file
View file

File diff suppressed because it is too large Load diff

28
slides/2-10.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.10: Creative Cryptography}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

974
slides/2-2.tex Normal file
View file

@ -0,0 +1,974 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.2: The Story of RC4}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\section{About RC4}
\begin{frame}{The Rise and Fall of RC4}
\begin{itemize}[<+->]
\item A cryptographic tale of triumph and tragedy
\begin{itemize}[<+->]
\item \textbf{Birth (1987):} Proprietary stream cipher at RSA Security
\item \textbf{Rise (1990s):} Became the world's most widely deployed stream cipher
\item \textbf{Golden Era (2000s):} Powered WEP, SSL, and TLS protocols globally
\item \textbf{Decline (2001-2015):} A series of devastating cryptanalytic breakthroughs
\item \textbf{Demise (2015):} Formal prohibition by IETF, browser vendors
\end{itemize}
\item This story teaches us about cryptographic lifecycle management, the importance of formal security analysis, and the challenges of maintaining backward compatibility
\end{itemize}
\end{frame}
\begin{frame}{What is RC4?}
\begin{itemize}[<+->]
\item \textbf{RC4} (Rivest Cipher 4) is a stream cipher designed for speed and simplicity
\begin{itemize}[<+->]
\item \textbf{Stream cipher:} Encrypts data one byte at a time
\item \textbf{Variable key length:} Supports keys from 1 to 256 bytes
\item \textbf{Symmetric encryption:} Same key used for encryption and decryption
\end{itemize}
\item Key characteristics that made it popular:
\begin{itemize}[<+->]
\item Extremely fast in software (no complex operations)
\item Small memory footprint (only 256 bytes of state)
\item Simple implementation (just a few lines of code)
\end{itemize}
\item Used extensively in protocols like WEP (Wi-Fi), SSL/TLS, and SSH
\end{itemize}
\end{frame}
\begin{frame}{Origins of RC4}
\begin{itemize}[<+->]
\item \textbf{1987:} Ron Rivest designs RC4 at RSA Security
\begin{itemize}[<+->]
\item Originally a trade secret, not published
\item ``RC'' stands for ``Ron's Code'' or ``Rivest Cipher''
\item Designed for practical applications requiring fast encryption
\end{itemize}
\item \textbf{1994:} Algorithm anonymously posted to Cypherpunks mailing list
\begin{itemize}[<+->]
\item Source code leaked, breaking RSA's trade secret
\item Called ``Alleged RC4'' or ``ARCFOUR'' due to legal concerns
\item Quickly reverse-engineered and verified as authentic
\end{itemize}
\item \textbf{Impact of the leak:}
\begin{itemize}[<+->]
\item Made RC4 freely available to implementers worldwide
\item Led to its widespread adoption in internet protocols
\item Ironically helped RSA by making their cipher ubiquitous
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{RC4's Key Scheduling Algorithm (KSA)}
\begin{itemize}[<+->]
\item \textbf{Step 1:} Initialize the state array S with values 0 through 255
\begin{itemize}[<+->]
\item \texttt{for i = 0 to 255: S[i] = i}
\end{itemize}
\item \textbf{Step 2:} Scramble the state array using the key
\begin{itemize}[<+->]
\item \texttt{j = 0}
\item \texttt{for i = 0 to 255:}
\item \texttt{\quad j = (j + S[i] + key[i mod keylength]) mod 256}
\item \texttt{\quad swap(S[i], S[j])}
\end{itemize}
\item \textbf{Purpose:} Create a pseudo-random permutation of 0-255 based on the key
\item The quality of this initial scrambling is crucial for security
\end{itemize}
\end{frame}
\begin{frame}{$\mathsf{PRP}: F_{k}= X \rightarrow X$}{Reminder}
\begin{columns}[c]
\begin{column}{0.4\textwidth}
\begin{itemize}
\item \textbf{Bijective} (two-way)
\begin{itemize}
\item \textbf{Injective}: no two inputs map to same output (no
collisions)
\item \textbf{Surjective}: Every output has one corresponding input
\end{itemize}
\item ``Randomized''
\item Relations between inputs not reflected in outputs
\end{itemize}
\end{column}
\begin{column}{0.8\textwidth}
\begin{tikzpicture}[scale=0.38]
% Define colors
\definecolor{domaingreen}{RGB}{102, 170, 68}
\definecolor{rangegreen}{RGB}{102, 170, 68}
\definecolor{circlecolor}{RGB}{235, 137, 85}
\definecolor{purplearrow}{RGB}{160, 78, 160}
% Input space (domain) X - made square
\draw[dashed, thick, domaingreen, fill=domaingreen]
(0,0) rectangle (8,8);
\node[text width=6.5cm, align=center, font=\normalsize]
at
(4,-0.8)
{Size: fixed};
\node[font=\normalsize] at (4,9) {Input space (domain) $X$};
% Output (range) Y - made square, same size as domain, moved left
\draw[thick, rangegreen, fill=rangegreen] (12,0) rectangle (20,8);
\node[text width=6.5cm, align=center, font=\normalsize]
at
(16,-0.8)
{Size: fixed};
\node[font=\normalsize] at (16,9) {Output (range) $X$};
% Input dots - adjusted positions for square domain
\filldraw[circlecolor] (2,7) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,7) -- (14.2,7.4);
\pause
\filldraw[circlecolor] (14.2,7.4) circle (0.3);
\pause
\filldraw[circlecolor] (3,6) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(3,6) -- (18.6,5.3);
\pause
\filldraw[circlecolor] (18.6,5.3) circle (0.3);
\pause
\filldraw[circlecolor] (2,5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,5) -- (13.8,4.2);
\pause
\filldraw[circlecolor] (13.8,4.2) circle (0.3);
\pause
\filldraw[circlecolor] (4,3.5) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(4,3.5) -- (17.4,2.2);
\pause
\filldraw[circlecolor] (17.4,2.2) circle (0.3);
\pause
\filldraw[circlecolor] (2,2) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(2,2) -- (16.1,6.7);
\pause
\filldraw[circlecolor] (16.1,6.7) circle (0.3);
\pause
\filldraw[circlecolor] (3,1) circle (0.3);
\pause
\draw[-{Stealth[length=6mm, width=4mm]}, thick, purplearrow]
(3,1) -- (19.0,1.4);
\pause
\filldraw[circlecolor] (19.0,1.4) circle (0.3);
\end{tikzpicture}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Limitations of One-Time Pad}{Reminder}
\definitionbox{The Key Length Problem}{
One-time pad is not a particularly useful encryption scheme in practice.
}
\begin{itemize}[<+->]
\item The key must be as long as the plaintext!
\item This creates a chicken-and-egg situation:
\begin{itemize}[<+->]
\item To privately send $n$ bits of information,
\item We must already privately share $n$ bits of information.
\end{itemize}
\item Impractical for most real-world applications.
\begin{itemize}[<+->]
\item Clearly this is not what we're doing when we use HTTPS,
\item or WhatsApp, or pay for something via a debit card...
\end{itemize}
\item We need encryption schemes where the key can be smaller than the message.
\end{itemize}
\end{frame}
\begin{frame}{Idea: find a way to expand the key}{Reminder}
\begin{itemize}[<+->]
\item Given a key $k_s$ of size $\left|k_s\right| < \left|m\right|$, find a way to obtain $\left|k_e\right| \geq \left|m\right|$
\item In the real world, we have two kinds of symmetric encryption schemes:
\begin{itemize}[<+->]
\item \textbf{Block ciphers}: AES, 3DES, etc.
\item \textbf{Stream ciphers}: ChaCha20, RC4, etc.
\end{itemize}
\item This is exactly what stream ciphers do!
\begin{itemize}[<+->]
\item Start with a small key $k_s$ of a fixed size $\left|k_s\right| = \lambda$,
\item Magically expand it to $k_e$ where $\left|k_e\right| \geq \left|m\right|$,
\item $\func{enc}{K, M} = K \oplus M$
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{RC4's Pseudo-Random Generation Algorithm (PRGA)}
\begin{itemize}[<+->]
\item \textbf{Initialization:} Set counters \texttt{i = 0, j = 0}
\item \textbf{For each byte to encrypt:}
\begin{itemize}[<+->]
\item \texttt{i = (i + 1) mod 256}
\item \texttt{j = (j + S[i]) mod 256}
\item \texttt{swap(S[i], S[j])}
\item \texttt{K = S[(S[i] + S[j]) mod 256]} \quad ← keystream byte
\item \texttt{ciphertext = plaintext XOR K}
\end{itemize}
\item \textbf{Key insight:} The state array S is continuously modified
\begin{itemize}[<+->]
\item Each keystream byte depends on the entire previous history
\item Creates a very long period before repetition
\end{itemize}
\item \textbf{Decryption:} Identical process (XOR is self-inverse)
\end{itemize}
\end{frame}
\begin{frame}{RC4's golden age (1990s-2000s)}
\begin{itemize}[<+->]
\item \textbf{The most widely deployed stream cipher in history}
\begin{itemize}[<+->]
\item Estimated to secure over 50\% of all SSL/TLS connections at its peak
\item Billions of devices worldwide relied on RC4 for encryption
\end{itemize}
\item \textbf{Ubiquitous protocol adoption:}
\begin{itemize}[<+->]
\item \textbf{WEP (1997):} Wi-Fi security standard used RC4 exclusively
\item \textbf{SSL 3.0/TLS 1.0 (1995-1999):} RC4 as preferred cipher suite
\item \textbf{SSH-1 (1995):} Early secure shell implementations
\item \textbf{Microsoft Office:} Document password protection
\item \textbf{Adobe PDF:} File encryption standard
\end{itemize}
\item \textbf{Why RC4 dominated:}
\begin{itemize}[<+->]
\item 5-10x faster than DES in software implementations
\item Minimal memory requirements (perfect for embedded systems)
\item No export restrictions (unlike strong block ciphers)
\item Simple to implement correctly
\end{itemize}
\end{itemize}
\end{frame}
\section{RSA in WEP}
\begin{frame}{Early RC4 weaknesses (1995-2000)}
\begin{itemize}[<+->]
\item \textbf{1995:} First statistical biases discovered by Wagner and Goldberg
\begin{itemize}[<+->]
\item Found that the second byte of RC4 keystream was biased
\item Probability of being zero was $2/256$ instead of $1/256$
\item Seemed like a minor curiosity at the time...
\end{itemize}
\item \textbf{1997:} Golic discovered more biases in the keystream
\begin{itemize}[<+->]
\item Certain byte positions showed statistical irregularities
\item Still considered mostly theoretical concerns
\end{itemize}
\item \textbf{2000:} Jenkins found patterns in RC4's internal state
\begin{itemize}[<+->]
\item Identified correlations between consecutive keystream bytes
\item Cryptographic community began to worry about RC4's security
\end{itemize}
\item \textbf{The stage was set} for a more devastating attack...
\end{itemize}
\end{frame}
\begin{frame}{Weak keys in KSA}
\begin{columns}[c]
\begin{column}{1\textwidth}
\begin{itemize}[<+->]
\item \textbf{The Discovery:} Certain key patterns create predictable initial states\footnote{\url{https://appliedcryptography.page/papers/rc4-ksa.pdf}}
\item \textbf{Weak Key Pattern:} Keys of the form $(K_1, K_2, \ldots, K_n, 3, 255, \ldots)$
\begin{itemize}[<+->]
\item When byte 3 of the key is 3, and byte 4 is 255
\item The KSA creates a predictable correlation in the state array
\end{itemize}
\item \textbf{The Mathematics:}
\begin{itemize}[<+->]
\item After KSA completes, $S[1] = 3$ with high probability
\item In the first step of PRGA: $i = 1, j = S[1] = 3$
\item First keystream byte: $S[S[1] + S[3]] = S[3 + S[3]]$
\item This reveals information about the key!
\end{itemize}
\item \textbf{Frequency:} About 1 in 256 keys exhibit this weakness
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{One-time secrecy of a SKE}{Reminder}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\definitionbox{One-time Secrecy for SKE}{
An SKE scheme $\Sigma$ has one-time secrecy if the following libraries are interchangeable:
\vspace{0.5mm}
\begin{center}
\sslinked{
\sslibrary{\Sigma}{ots-real}{
\sslibrarysubroutine{ots.enc}{M}{
$K \twoheadleftarrow \Sigma.\mathcal{K}$ \\
$C \coloneq \Sigma.\textsf{Enc}(K, M)$ \\
return $C$
}{1}
}{0.8}
}{\interchangeable{}}{
\sslibrary{\Sigma}{ots-rand}{
\sslibrarysubroutine{ots.enc}{M}{
$C \twoheadleftarrow \Sigma.\mathcal{C}$ \\
return $C$
}{1}
}{0.8}
}
\end{center}
}
\end{column}
\begin{column}{0.5\textwidth}
An encryption scheme has one-time secrecy if its ciphertexts are uniformly distributed, when keys are sampled uniformly, kept secret, and used for only one encryption, and no matter how the plaintexts are chosen.
\\
\textbf{Does this apply to RC4, especially after the attacks?}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Attacks mean distinguishability}{RC4 getting less and less ``indistinguishable from random''}
\begin{columns}[c]
\begin{column}{0.35\textwidth}
\sssubroutine{RC4Encrypt}{M}{
$k \twoheadleftarrow \bits^{\lambda}$ \\
$K \coloneq \texttt{RC4}(k, |M|)$ \\
$C \coloneq K \oplus M$ \\
return $C$
}{1.5}
\end{column}
\begin{column}{0.3\textwidth}
\begin{center}
{\huge{$\cancel{\approxeq}$}} \\[1em]
\end{center}
\end{column}
\begin{column}{0.35\textwidth}
\sssubroutine{Random}{M}{
$C \twoheadleftarrow \bits^{|M|}$ \\
return $C$
}{1.5}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{In fact...}
\bigimagewithcaption{rc4_bias.png}{Source: Kenny Paterson}
\end{frame}
\begin{frame}{Attacks: from theory to practice}
\begin{itemize}[<+->]
\item \textbf{Step 1:} Collect many ciphertexts encrypted with related keys
\begin{itemize}[<+->]
\item Keys that differ only in the first few bytes
\item Wait for keys with the vulnerable pattern to appear
\end{itemize}
\item \textbf{Step 2:} Identify weak keys from keystream patterns
\begin{itemize}[<+->]
\item Look for the telltale signatures in the first keystream byte
\item Discard non-vulnerable encryptions
\end{itemize}
\item \textbf{Step 3:} Recover key bytes incrementally
\begin{itemize}[<+->]
\item Use the correlation to determine likely values for key bytes
\item Build up the key one byte at a time
\end{itemize}
\item \textbf{Success rate:} With enough samples, key recovery becomes highly reliable
\end{itemize}
\end{frame}
\begin{frame}{How WEP encryption works}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item \textbf{Components:}
\begin{itemize}[<+->]
\item 24-bit IV (Initialization Vector)
\item 104-bit PSK (pre-shared key)
\begin{itemize}
\item Derived from Wi-Fi password
\item Was limited to 40 bits at first due to US export controls!
\end{itemize}
\end{itemize}
\item \textbf{Process:}
\begin{itemize}[<+->]
\item Choose random IV for each packet
\item Concatenate: IV $\|$ Secret Key
\item Feed to RC4 to generate keystream
\item XOR plaintext with keystream
\end{itemize}
\end{itemize}
\begin{center}
\begin{tikzpicture}[scale=0.7]
% Transmitted packet
\draw[thick, dashed] (-0.5,-5) rectangle (7,-6);
\draw[thick, fill=blue!20] (0,-5.2) rectangle (2,-5.8);
\node at (1,-5.5) {IV};
\draw[thick, fill=gray!20] (2.5,-5.2) rectangle (6.5,-5.8);
\node at (4.5,-5.5) {Ciphertext};
\node[below] at (3.25,-6) {\small Transmitted Packet};
\end{tikzpicture}
\end{center}
\end{column}
\begin{column}{0.5\textwidth}
\begin{center}
\begin{tikzpicture}[scale=0.7]
% IV Box
\draw[thick, fill=blue!20] (0,4) rectangle (2,5);
\node at (1,4.5) {IV};
\node[below] at (1.7,3.8) {\tiny 24 bits};
% Secret Key Box
\draw[thick, fill=red!20] (2.5,4) rectangle (5.5,5);
\node at (4,4.5) {Secret Key};
\node[below] at (5,3.8) {\tiny 104 bits};
% Concatenation
\draw[->, thick] (1,4) -- (1,3);
\draw[->, thick] (4,4) -- (4,3);
\draw[thick] (0.5,2.25) rectangle (4.5,3);
\node at (2.5,2.6) {IV $\|$ Key};
% RC4 Box
\draw[->, thick] (2.5,2.25) -- (2.5,1.5);
\draw[thick, fill=green!20] (1,0.5) rectangle (4,1.5);
\node at (2.5,1) {RC4};
% Keystream
\draw[->, thick] (2.5,0.5) -- (2.5,-0.5);
\node at (2.5,-0.8) {Keystream};
% Plaintext
\draw[thick, fill=yellow!20] (6,0.5) rectangle (8.5,1.5);
\node at (7.25,1) {Plaintext};
% XOR
\draw[->, thick] (2.5,-1) -- (5,-1);
\draw[->, thick] (7.25,0.5) -- (7.25,-0.5) -- (5.5,-0.5) -- (5.5,-1);
\draw[thick] (5,-1.5) circle (0.5);
\node at (5,-1.5) {$\oplus$};
% Ciphertext
\draw[->, thick] (5,-2) -- (5,-3);
\draw[thick, fill=gray!20] (3.5,-3) rectangle (6.5,-4);
\node at (5,-3.5) {Ciphertext};
\end{tikzpicture}
\end{center}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{WEP: the perfect storm}
\begin{columns}[c]
\begin{column}{1\textwidth}
\begin{itemize}[<+->]
\item \textbf{WEP (Wired Equivalent Privacy):} Wi-Fi security protocol from 1997
\begin{itemize}[<+->]
\item Used RC4 for encryption
\item 104-bit secret key shared among all devices
\end{itemize}
\item \textbf{Vulnerable design choice:} Initialization Vectors (IVs)
\begin{itemize}[<+->]
\item To avoid key reuse, WEP prepends a 24-bit IV to each packet
\item RC4 key becomes: $(IV_1, IV_2, IV_3, K_1, K_2, \ldots, K_n)$
\item IV is sent \emph{in plaintext} with each packet!
\end{itemize}
\item \textbf{Break:} This creates exactly the conditions the FMS (Fluhrer, Mantin, Shamir) attack exploited
\begin{itemize}[<+->]
\item Many related keys (same secret key, different IVs)
\item Attacker knows the first 3 bytes of each key (the IV)
\item Perfect setup for the FMS attack!
\end{itemize}
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{WEP's IV structure}
\begin{center}
\begin{tikzpicture}[scale=0.6]
\draw[thick] (0,2) rectangle (2,3);
\node at (1,2.5) {\scriptsize IV Byte 1};
\draw[thick] (2,2) rectangle (4,3);
\node at (3,2.5) {\scriptsize IV Byte 2};
\draw[thick] (4,2) rectangle (6,3);
\node at (5,2.5) {\scriptsize IV Byte 3};
\draw[thick, fill=red!20] (6,2) rectangle (8,3);
\node at (7,2.5) {\scriptsize $K_1$};
\draw[thick, fill=red!20] (8,2) rectangle (10,3);
\node at (9,2.5) {\scriptsize $K_2$};
\draw[thick, fill=red!20] (10,2) rectangle (12,3);
\node at (11,2.5) {\scriptsize $\ldots$};
\node[above] at (3,3.2) {\textbf{Known to Attacker}};
\node[above] at (9,3.2) {\textbf{Secret Key (Target)}};n
\draw[->, thick, red] (1,1.5) -- (1,2);
\node[below, red, text width=5cm, align=center] at (1,1.2) {\textbf{IVs like $(3, 255, x)$}};
\draw[->, thick, red] (7,1.5) -- (7,0.5);
\node[below, red] at (7,0.3) {\textbf{Reveal $K_1$}};
\end{tikzpicture}
\end{center}
\begin{itemize}[<+->]
\item \textbf{The FMS Attack:} Exploits weak IV patterns of form $(A+3, 255, x)$
\item \textbf{Pattern:} To attack key byte $K_A$, wait for IVs $(A+3, 255, x)$
\item \textbf{Frequency:} About 1 in 65,536 packets match the vulnerable pattern
\item \textbf{Collection:} Need multiple matching IVs per key byte for statistical attack
\item \textbf{Result:} With enough packets, incrementally recover the entire key
\end{itemize}
\end{frame}
\begin{frame}{Practical tools}
\begin{itemize}[<+->]
\item \textbf{AirSnort (2001):} First practical WEP cracking tool
\begin{itemize}[<+->]
\item Implemented the FMS attack
\item Could crack WEP keys with 1-5 million packets
\item Made WEP cracking accessible to non-experts
\end{itemize}
\item \textbf{WEPCrack (2001):} Another early implementation
\begin{itemize}[<+->]
\item Demonstrated the attack's effectiveness
\item Confirmed that WEP was fundamentally broken
\end{itemize}
\item \textbf{Aircrack-ng (2006):} Improved and optimized tools
\begin{itemize}[<+->]
\item Reduced required packets to hundreds of thousands
\item Added packet injection to speed up attacks
\item Still widely used today for security testing
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Attack: step by step}
\begin{itemize}[<+->]
\item \textbf{Step 1:} Attacker sets Wi-Fi card to monitor mode
\begin{itemize}[<+->]
\item Passively collects all WEP-encrypted packets
\item No need to associate with the target network
\end{itemize}
\item \textbf{Step 2:} Filter for packets with vulnerable IVs
\begin{itemize}[<+->]
\item Look for ``weak IVs''
\item Collect the corresponding keystream bytes
\end{itemize}
\item \textbf{Step 3:} Apply statistical analysis
\begin{itemize}[<+->]
\item Use FMS attack to determine most likely key byte values
\item Incrementally build up the secret key
\end{itemize}
\item \textbf{Step 4:} Verify the recovered key
\begin{itemize}[<+->]
\item Test against captured packets
\item Success: Complete compromise of the Wi-Fi network!
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Attacks only get better}
\begin{itemize}[<+->]
\item \textbf{Klein's Attack (2005):} Extended the vulnerable IV patterns
\begin{itemize}[<+->]
\item Found additional weak key structures
\item Reduced the number of packets needed for key recovery
\end{itemize}
\item \textbf{PTW Attack (2007):} Pyshkin, Tews, and Weinmann
\begin{itemize}[<+->]
\item Revolutionary approach using Bayes' theorem
\item Could crack WEP with as few as 40,000 packets
\item Made attacks feasible on even low-traffic networks
\end{itemize}
\item \textbf{Key Recovery Speedup:} From hours to minutes
\begin{itemize}[<+->]
\item Modern attacks can crack WEP in under 10 minutes
\item Some demonstrations crack it in under 60 seconds
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Lessons learned from WEP}
\begin{itemize}[<+->]
\item \textbf{Lesson 1:} Never use a stream cipher with related keys
\begin{itemize}[<+->]
\item WEP's IV structure created exactly this scenario
\item Modern protocols use proper key derivation functions
\end{itemize}
\item \textbf{Lesson 2:} Academic attacks become practical faster than expected
\begin{itemize}[<+->]
\item FMS attack went from paper to tool in months
\item ``Theoretical'' often means ``practical soon''
\end{itemize}
\item \textbf{Lesson 3:} Security protocols need formal analysis
\begin{itemize}[<+->]
\item WEP was designed by committee without cryptographic rigor
\item Modern protocols undergo extensive peer review
\end{itemize}
\item \textbf{Lesson 4:} Backward compatibility can be a security nightmare
\begin{itemize}[<+->]
\item WEP remained deployed long after being broken
\item Organizations were slow to migrate due to cost/complexity
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{WEP timeline}
\begin{itemize}[<+->]
\item \textbf{2001:} FMS attack published - WEP theoretically broken
\item \textbf{2001:} AirSnort released - WEP practically broken
\item \textbf{2003:} WPA (Wi-Fi Protected Access) standardized as replacement
\item \textbf{2004:} WPA2 released with AES encryption
\item \textbf{2006:} Wi-Fi Alliance deprecates WEP
\item \textbf{2012:} WEP support removed from Windows 8
\item \textbf{2018:} Many vendors stop supporting WEP entirely
\item \textbf{Today:} WEP is considered a historical curiosity
\end{itemize}
\end{frame}
\section{RC4 in TLS}
\begin{frame}{RC4 in TLS: from preferred to prohibited}
\begin{itemize}[<+->]
\item \textbf{RC4's role in TLS/SSL:} Once the default stream cipher
\begin{itemize}[<+->]
\item Preferred over block ciphers due to speed
\item No need for padding (unlike CBC mode)
\item Avoided the BEAST attack against CBC ciphers
\end{itemize}
\item \textbf{2011:} BEAST attack made RC4 more attractive
\begin{itemize}[<+->]
\item Attack on CBC mode in TLS 1.0
\item Many servers switched to RC4-only cipher suites
\item RC4 usage actually increased!
\end{itemize}
\item \textbf{The irony:} Avoiding one attack led directly into another
\begin{itemize}[<+->]
\item RC4's biases were known but considered impractical
\item This assumption would prove catastrophically wrong
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{AlFardan et al. (2013): RC4 biases in TLS}
\begin{columns}[c]
\begin{column}{0.6\textwidth}
\begin{itemize}[<+->]
\item \textbf{The discovery:} RC4's biases are exploitable in TLS:\footnote{\url{https://appliedcryptography.page/papers/rc4-tls.pdf}}
\begin{itemize}[<+->]
\item First 256 bytes of keystream heavily biased
\item Certain byte positions more predictable than others
\item Biases persist even with proper key generation
\end{itemize}
\item \textbf{Key finding:} Single-byte biases
\begin{itemize}[<+->]
\item Position 1: $\Pr[Z_1 = 0] \approx 2^{-7}$ (double expected)
\item Position 2: $\Pr[Z_2 = 0] \approx 2^{-7}$ (double expected)
\item Positions 3-255: Various smaller biases
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.4\textwidth}
\begin{itemize}[<+->]
\item \textbf{Multi-byte biases:} Even stronger patterns
\begin{itemize}[<+->]
\item $(Z_1, Z_{257}) = (0, 0)$ with probability $2^{-11}$
\item Should be $2^{-16}$ if truly random
\item 32 times more likely than expected!
\end{itemize}
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{The broadcast attack scenario}
\begin{itemize}[<+->]
\item \textbf{Attack model:} Same plaintext encrypted many times
\begin{itemize}[<+->]
\item HTTP cookies sent with every request
\item Session tokens in fixed positions
\item Password fields in web forms
\end{itemize}
\item \textbf{The mathematics:} Bias accumulation
\begin{itemize}[<+->]
\item Collect ciphertexts: $C_1, C_2, \ldots, C_n$
\item For position $i$: count occurrences of each byte value
\item Most frequent ciphertext byte reveals plaintext byte
\item Required samples: $\mathcal{O}(N \cdot B^{-2})$ where $B$ is bias
\end{itemize}
\item \textbf{Practical requirements:}
\begin{itemize}[<+->]
\item $2^{24}$ to $2^{30}$ encryptions needed
\item Feasible for persistent attackers
\item JavaScript injection can generate traffic
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Garman et al. (2015): attacks only get better}
\begin{columns}[c]
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item \textbf{The challenge:} AlFardan et al.'s attack was still ``impractical''
\begin{itemize}[<+->]
\item Required billions of encryptions
\item Took days or weeks to execute
\item Many dismissed it as theoretical
\end{itemize}
\item \textbf{Insight:} Target password verifiers, not cookies\footnote{\url{https://appliedcryptography.page/papers/rc4-attacks.pdf}}
\begin{itemize}[<+->]
\item Basic Authentication sends passwords in every request
\item IMAP/SMTP use similar repeated authentication
\item Password structure provides additional constraints
\end{itemize}
\end{itemize}
\end{column}
\begin{column}{0.5\textwidth}
\begin{itemize}[<+->]
\item \textbf{The improvements:} Orders of magnitude faster
\begin{itemize}[<+->]
\item Exploit password character distributions
\item Use Mantin's ABSAB bias (positions 1-4)
\item Combine with dictionary attacks
\item Other attack papers use similar techniques, including to break WPA-TKIP, a successor to WEP!\footnote{\url{https://appliedcryptography.page/papers/rc4-biases.pdf}}
\end{itemize}
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{Mantin's ABSAB bias (2005)}
\begin{itemize}[<+->]
\item \textbf{The discovery:} Certain digraph patterns repeat with anomalous frequency\footnote{\url{https://appliedcryptography.page/papers/rc4-absab.pdf}}
\begin{itemize}[<+->]
\item Pattern: Two characters repeat after a gap (e.g., ABAB, ABCAB)
\item Occurs when value 1 is used to update index $j$ in RC4
\item Creates correlations between distant output positions
\end{itemize}
\item \textbf{The mathematics:} For pattern AB...AB with gap $G$
\begin{itemize}[<+->]
\item Expected probability in random: $1/N^2$
\item Actual probability in RC4: $(1 + e^{(-4-8G)/N}/N) \cdot 1/N^2$
\item Relative bias: $\approx 1/N$ for zero gap, decreases with gap size
\end{itemize}
\item \textbf{Why it matters:}
\begin{itemize}[<+->]
\item Enables distinguishing attacks with only $2^{26}$ samples
\item Can predict individual bytes with 82\% accuracy after $2^{50}$ samples
\item Particularly effective against password-based authentication
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{ABSAB bias in action: practical example}
\begin{itemize}[<+->]
\item \textbf{Target:} Password ``hello123'' in HTTP Basic Authentication
\item \textbf{Step 1:} Password encoded as base64: ``aGVsbG8xMjM=''
\item \textbf{Step 2:} Look for ABSAB patterns in collected ciphertexts:
\begin{center}
\begin{tikzpicture}[scale=0.8]
\foreach \i/\char in {0/h,1/e,2/l,3/l,4/o,5/1,6/2,7/3} {
\draw[thick] (\i*1.2,2) rectangle (\i*1.2+1,3);
\node at (\i*1.2+0.5,2.5) {\texttt{\char}};
}
\draw[red, ultra thick] (2*1.2-0.1,1.9) rectangle (3*1.2+1.1,3.1);
\node[red, below] at (5,1.75) {Repeated ``ll'' pattern};
\draw[->, thick, blue] (2.5,1) -- (2.5,1.8);
\node[blue, below] at (2.5,1) {ABSAB: $(l,l,*,l,l)$ occurs 1024× more!};
\end{tikzpicture}
\end{center}
\item \textbf{Step 3:} After $2^{26}$ samples, frequency analysis reveals:
\begin{itemize}[<+->]
\item Positions 2-3: ``ll'' pattern confirmed via ABSAB
\item Position 0: ``h'' (68/256 occurrences)
\item Position 1: ``e'' (65/256 occurrences)
\item Password structure revealed: ``h\_ll\_\_\_\_''
\end{itemize}
\item \textbf{Result:} Search space reduced from $62^8$ to $62^4$ possibilities!
\end{itemize}
\end{frame}
\begin{frame}{Password recovery: the numbers}
\begin{itemize}[<+->]
\item \textbf{Basic Authentication attack performance:}
\begin{itemize}[<+->]
\item 6-character passwords: $2^{26}$ encryptions
\item Time: ~50-100 hours.
\end{itemize}
\item \textbf{IMAP attack results:}
\begin{itemize}[<+->]
\item Real passwords recovered in laboratory setting
\item Character-by-character recovery possible
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{POODLE (2014): the final nail}
\begin{itemize}[<+->]
\item \textbf{POODLE:} Padding Oracle On Downgraded Legacy Encryption
\begin{itemize}[<+->]
\item Not specifically an RC4 attack
\item But exploited SSL 3.0's MAC-then-encrypt with CBC
\item Led to mass exodus from SSL 3.0
\end{itemize}
\item \textbf{The downgrade dance:}
\begin{itemize}[<+->]
\item Attackers force TLS connections to fail
\item Browsers retry with older SSL 3.0
\item SSL 3.0 has no downgrade protection!
\end{itemize}
\item \textbf{Why this matters for RC4:}
\begin{itemize}[<+->]
\item SSL 3.0 heavily used RC4
\item POODLE + RC4 biases = from compromise to compromise
\item Final push to deprecate both SSL 3.0 and RC4
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Coordinated response between vendors}
\begin{itemize}[<+->]
\item \textbf{2013:} IETF begins discussing RC4 deprecation
\begin{itemize}[<+->]
\item Working groups start planning migration
\end{itemize}
\item \textbf{2014/2015:} Major browsers act
\begin{itemize}[<+->]
\item Chrome/Firefox announce RC4 phase-out plans
\item Microsoft issues security advisories
\item Apple begins removing RC4 from Safari
\end{itemize}
\item \textbf{2015:} RFC 7465 prohibits RC4 in TLS
\begin{itemize}[<+->]
\item ``TLS clients MUST NOT include RC4 cipher suites''
\item ``TLS servers MUST NOT select RC4 cipher suites''
\item Formal end of RC4 in internet protocols
\end{itemize}
\item \textbf{2016/2018:} RC4 removed from all major browsers
\end{itemize}
\end{frame}
\begin{frame}{Technical lessons from RC4's demise}
\begin{itemize}[<+->]
\item \textbf{Lesson 1:} Statistical biases matter at scale
\begin{itemize}[<+->]
\item ``Small'' biases become exploitable with enough data
\item Modern internet generates massive data volumes
\item Never dismiss statistical irregularities
\end{itemize}
\item \textbf{Lesson 2:} Attacks combine in unexpected ways
\begin{itemize}[<+->]
\item ABSAB bias + password structure = practical attack
\item Protocol downgrade + cipher weakness = disaster
\end{itemize}
\item \textbf{Lesson 3:} Migration is painful but necessary
\begin{itemize}[<+->]
\item RC4 removal broke many legacy systems
\item But waiting would have been catastrophic
\item Plan for crypto-agility from the start
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{RC4: a complete timeline}
\begin{itemize}[<+->]
\item \textbf{1987:} Ron Rivest designs RC4
\item \textbf{1994:} Algorithm leaked to cypherpunks
\item \textbf{1995-2000:} Early bias discoveries
\item \textbf{2001:} FMS attack breaks WEP
\item \textbf{2011:} BEAST attack increases RC4 usage
\item \textbf{2013:} AlFardan et al. show TLS attacks are almost practical
\item \textbf{2014:} POODLE compromises SSL 3.0
\item \textbf{2015:} Garman et al. improves password recovery
\item \textbf{2015:} IETF prohibits RC4 (RFC 7465)
\item \textbf{2016:} RC4 removed from browsers
\item \textbf{Today:} RC4 is cryptographically dead
\end{itemize}
\end{frame}
\begin{frame}{The broader impact}
\begin{itemize}[<+->]
\item \textbf{On cryptographic design:}
\begin{itemize}[<+->]
\item Stream ciphers now use different designs (ChaCha20)
\item Focus on provable security properties
\item Extensive bias analysis before deployment
\end{itemize}
\item \textbf{On protocol design:}
\begin{itemize}[<+->]
\item TLS 1.3 removed all weak ciphers
\item Mandatory authenticated encryption (AEAD)
\item No more downgrade attacks
\end{itemize}
\item \textbf{On deployment practices:}
\begin{itemize}[<+->]
\item Regular security audits of cipher suites
\item Sunset dates for algorithms
\item Crypto-agility built into protocols
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{Modern alternatives to RC4}
\begin{itemize}[<+->]
\item \textbf{ChaCha20-Poly1305:} The modern stream cipher
\begin{itemize}[<+->]
\item Designed by Daniel J. Bernstein
\item No known biases after extensive analysis
\item Includes authentication (AEAD)
\end{itemize}
\item \textbf{AES-GCM:} The block cipher alternative
\begin{itemize}[<+->]
\item Hardware acceleration on modern CPUs
\item Well-studied security properties
\item Standard choice for TLS 1.3
\end{itemize}
\item \textbf{Key differences from RC4:}
\begin{itemize}[<+->]
\item Authenticated encryption prevents tampering
\item No statistical biases in keystream
\item Designed with modern cryptanalysis in mind
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}{RC4: final thoughts}
\begin{itemize}[<+->]
\item \textbf{A cipher of its time:}
\begin{itemize}[<+->]
\item Perfect for 1990s hardware constraints
\item Served the early internet well
\item But couldn't survive modern cryptanalysis
\end{itemize}
\item \textbf{The lifecycle of cryptography:}
\begin{itemize}[<+->]
\item All ciphers eventually fall
\item Plan for migration from day one
\item Monitor academic literature for early warnings
\end{itemize}
\item \textbf{The human element:}
\begin{itemize}[<+->]
\item Ron Rivest's elegant design lasted 28 years
\item Cryptographers who broke it built on decades of research
\item The cycle continues with new algorithms and new attacks
\end{itemize}
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

1837
slides/2-3.tex Normal file
View file

File diff suppressed because it is too large Load diff

28
slides/2-4.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.4: Applied Cryptography in Cloud Security}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

28
slides/2-5.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.5: High-Assurance Cryptography}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

28
slides/2-6.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.6: Cryptocurrency Cryptography}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

28
slides/2-7.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.7: Post-Quantum Cryptography}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

28
slides/2-8.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.8: Zero-Knowledge Proofs}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

28
slides/2-9.tex Normal file
View file

@ -0,0 +1,28 @@
\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}
\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.9: Secure Multiparty Computation}
\coverwebsite{https://appliedcryptography.page}
\begin{document}
\begin{frame}[plain]
\titlepage
\end{frame}
\begin{frame}{Slides not complete and may contain errors}
\begin{itemize}
\item This slide deck is not finished, may contain errors, and is missing important material. Do not rely on it yet.
\end{itemize}
\end{frame}
\begin{frame}[plain]
\titlepage
\end{frame}
\end{document}

73
slides/Makefile Normal file
View file

@ -0,0 +1,73 @@
all:
@make 1-1
@make 1-2
@make 1-3
@make 1-4
@make 1-5
@make 1-6
@make 1-7
@make 1-8
@make 2-1
@make 2-2
@make 2-3
@make 2-4
@make 2-5
@make 2-6
@make 2-7
@make 2-8
@make 2-9
@make 2-10
1-1:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-1.tex"
1-2:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-2.tex"
1-3:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-3.tex"
1-4:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-4.tex"
1-5:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-5.tex"
1-6:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-6.tex"
1-7:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-7.tex"
1-8:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "1-8.tex"
2-1:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-1.tex"
2-2:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-2.tex"
2-3:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-3.tex"
2-4:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-4.tex"
2-5:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-5.tex"
2-6:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-6.tex"
2-7:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-7.tex"
2-8:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-8.tex"
2-9:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-9.tex"
2-10:
@export SOURCE_DATE_EPOCH=1700000000 && tectonic -o ../website/slides "2-10.tex"

37
slides/README.md Normal file
View file

@ -0,0 +1,37 @@
# Slides
Welcome to the slides! Here they are. Isn't that amazing?
## Readiness status
I'm still working on the slides. If the checkbox isn't checked, it means you shouldn't use them yet.
#### Part 1
**Complete!**
#### Part 2
- [x] Part 2: Topic 1
- [ ] Part 2: Topic 2
- [ ] Part 2: Topic 3
- [ ] Part 2: Topic 4
- [ ] Part 2: Topic 5
- [ ] Part 2: Topic 6
- [ ] Part 2: Topic 7
- [ ] Part 2: Topic 8
- [ ] Part 2: Topic 9
- [ ] Part 2: Topic 10
## Compiling the slides
You'll need to first have [Tectonic](https://tectonic-typesetting.github.io/en-US/) installed. The good news is that this means that you don't need to install LaTeX!
## Notes
### Regarding handout mode
By default, these slides are presented in "handout mode", meaning they don't have transitions. If you want to compile them a slide deck with transitions (useful during teaching), remove the `handout` directive from the first line of the slide deck, and then run the corresponding `make` command.
### Converting from SVG
This is for my use only, please ignore:
`magick -density 4000 input.svg -resize 4000x output.png`

BIN
slides/images/aead_scenario_1.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/aead_scenario_2.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/aead_scenario_4.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/aes_subbytes.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/attacker_interface.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/attacker_interface_prog.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/aub_white.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/battleship.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/block_cipher_modes.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/caesar.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/cbc_with_dec.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/cedar.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/clock_13.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/complexity.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/ctr_dec.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/ctr_dec_delta.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/ctr_with_dec.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/deep_crack_a.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/deep_crack_b.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/dh.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/djb.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/elliptic_curve_add.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/elliptic_curve_double.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/elliptic_curve_integers.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/elliptic_curve_real.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/export_1.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/export_2.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/export_3.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/feistel_cipher.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/feistel_cipher_inv.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/fischer.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/fischer_sectioned.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/fischer_theory.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/fischer_tls_13_bubbles.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/gcm.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/gpu_farm.jpg (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/keyed_enc.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/letsencrypt_certs.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/letsencrypt_https.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/letsencrypt_issuance.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/logjam_1.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/logjam_2.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/logjam_3.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/merkle_damgard.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/naive_enc.pdf (Stored with Git LFS) Normal file
View file

Binary file not shown.

BIN
slides/images/nist_peanut.png (Stored with Git LFS) Normal file
View file

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show more