\documentclass[landscape]{slides}

\newif\ifpdf
\ifx\pdfoutput\undefined
   \pdffalse
\else
   \pdfoutput=1
   \pdftrue
\fi

\begin{document}
\ifpdf
  \pdfcompresslevel=9
  \pdfpagewidth=\the\paperwidth
  \pdfpageheight=\the\paperheight
\fi

% slide 1
\begin{slide}
\begin{center}
A Reputation System to Increase MIX-net Reliability\\
\vspace{1in}
The Free Haven Project\\
\vspace{.5in}
Roger Dingledine, Reputation Technologies\\
Michael Freedman, MIT Lab for Computer Science\\
David Hopwood, Independent consultant\\
David Molnar, Harvard University
\end{center}
\end{slide}

% slide 2
\begin{slide}
\begin{center}
The Problem
\end{center}
\begin{itemize}
\item The current remailer infrastructure is
\begin{itemize}
\item unreliable (dropped/repeated messages)
\item inefficient (high/unpredictable latency)
\end{itemize}
\item Unreliability decreases anonymity
\end{itemize}
\end{slide}

% slide 3
\begin{slide}
\begin{center}
Improving Reliability
\end{center}
\begin{itemize}
\item Build protocols with provable reliability guarantees
\item Add reputation to ``improve'' reliability
\item Provide economic incentives for reliability
\vspace{1in}
\item Distinction between reliability and robustness
%  \begin{itemize} 
%  \item Robustness: 
%  \end{itemize}
\end{itemize}
\end{slide}

% slide 4

\begin{slide}
\begin{center}
Related Work
\end{center}
\begin{itemize}
%fixme - add reference markers
\item MIXes (Chaum)
\item Robust MIX-nets (Flash Mix, Universally Verifiable MIX) 
\item Deployed Remailer Systems (cypherpunks, Mixmaster)
\item Remailer statistics (Levien's statistics, Jack B Nymble 2)
\end{itemize}
\end{slide}

% slide 5
\begin{slide}
\begin{center}
Need to Verify Failures
\end{center}
\begin{itemize}
\item Verifying successes is not useful: spoofing is easy
\item Failures represent MIX unreliability
\item Forcing failures \emph{is} unreliability
\end{itemize}
\end{slide}

% slide 6
\begin{slide}
\begin{center}
Ways To Verify Failures
\end{center}
\begin{itemize}
\item Publish all intermediate messages (public ledger)
\item Web MIXes
\item Witnesses and Receipts
\end{itemize}
\end{slide}

% slide 7
\begin{slide}
\begin{center}
Witnesses and Receipts to Verify Failures
\end{center}
\begin{itemize}
\item $N_{i+1}$ gives $N_i$ a receipt for each accepted message
\item Each message has a deadline after which it has ``failed'' % [actually, several deadlines]
\item If $N_i$ fails to deliver, he asks witnesses to try
\item Witness returns receipt if success, else a failure statement
\item Thus senders can check receipts and claim failures
\end{itemize}
\end{slide}

% slide 8
\begin{slide}
\begin{center}
Good MIXes demonstrate honesty
\end{center}
\begin{itemize}
\item Honest $N_i$ delivers to $N_{i+1}$ or to witnesses
\item \dots and receives either a receipt or a set of witness statements
\item If sender challenges, he can provide receipt or statements\\
(Majority of statements is credible)
\end{itemize}
\end{slide}

% slide 9
\begin{slide}
\begin{center}
Bad MIXes Are Caught
\end{center}
\begin{itemize}
\item Attacks: don't accept, or silently drop
\item Witnesses will catch MIXes that don't accept
\item MIXes that silently drop can't show receipts/statements
\item Sender claims failure to witnesses, who check
\end{itemize}
%\item A bad $N_{i+1}$ either gives $N_i$ a receipt or not
%\item If he doesn't, then witness statements implicate him
%\item If he does, he
%  - gets a receipt from N_{i+2}, meaning he's not bad
%  - asks witnesses to deliver, meaning he's not bad
%  - else
\end{slide}

% slide 10
\begin{slide}
\begin{center}
Reputation System Requirements
\end{center}
\begin{itemize}
\item Automated: sender software automatically uses reputations
\item Verifiable: reputations can be verified; claims can be checked
\item Dynamic: e.g. reflect recent trends in behavior
\item Must maintain anonymity provided by MIX-net
\end{itemize}
\end{slide}

% slide 11
\begin{slide}
\begin{center}
Our Reputation System
\end{center}
\begin{itemize}
\item Witnesses are scorers: tally failure claims from MIXes and senders
\item Scorers send test messages to get verified successes
\item Scorers publish scores; sender software automatically chooses paths
\item Senders throw out MIXes w/out some threshold of successes,
then weight remaining MIXes by number of failures
\end{itemize}
\end{slide}

% slide 12
\begin{slide}
\begin{center}
Traffic Analysis
\end{center}
\begin{itemize}
\item Messages to witnesses unencrypted for public verification
\item Higher reputation $\Rightarrow$ more traffic to analyze
\item Adversary can sabotage other nodes to get more traffic
\item But greater reliability $\Rightarrow$ more users $\Rightarrow$ stronger anonymity
\end{itemize}
\end{slide}

% slide 13
\begin{slide}
\begin{center}
Future Directions
\end{center}
\begin{itemize}
\item Reliability metric and model (same with efficiency)
\item Other reliability approaches, e.g. through payment?
\item Remove witnesses if possible (universally verifiable
      reputation system), maintaining practicality.
\end{itemize}
\end{slide}

\end{document}