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

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.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

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

Binary file not shown.

BIN
slides/images/xor_enc.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