--- a/slides/slides04.tex	Fri Oct 21 21:15:47 2016 +0100
+++ b/slides/slides04.tex	Wed Oct 26 00:52:18 2016 +0100
@@ -1226,61 +1226,13 @@
 
 \begin{itemize}
 \item even the systems designed by experts regularly fail\medskip
-\item try to make everything explicit (you need to authenticate all data you might rely on)\medskip
 \item the one who can fix a system should also be liable for the losses\medskip
-\item cryptography is often not {\bf the} answer\bigskip\bigskip  
+\item cryptography is often not the problem\bigskip\bigskip  
 \end{itemize}
 
 \end{frame}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\begin{frame}[c]
-\frametitle{Best Practices}
-
-{\bf Principle 1:} Every message should say what it means: the interpretation of 
-a message should not depend on the context.\bigskip\pause
-
-{\bf Principle 2:} If the identity of a principal is essential to the meaning of a message, it is prudent 
-to mention the principal’s name explicitly in the message (though difficult).\bigskip
-
-\end{frame}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\begin{frame}[c]
-
-{\bf Principle 3:} Be clear about why encryption is being
-done. Encryption is not cheap, and not asking precisely why it is
-being done can lead to redundancy. Encryption is not synonymous with
-security.
-
-\begin{center}
-Possible Uses of Encryption
-
-\begin{itemize}
-\item Preservation of confidentiality: \bl{$\{X\}_K$} only those that have \bl{$K$} may recover \bl{$X$}.
-\item Guarantee authenticity: The partner is indeed some particular principal.
-\item Guarantee confidentiality and authenticity: binds two parts of a message --- 
-\bl{$\{X,Y\}_K$} is not the same as \bl{$\{X\}_K$} and \bl{$\{Y\}_K$}.
-\end{itemize}
-\end{center}
-
-\end{frame}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\begin{frame}[c]
-\frametitle{Best Practices}
-
-{\bf Principle 4:} The protocol designer should know which trust relations his protocol depends on, and why the dependence is necessary. The reasons for particular trust relations being acceptable should be explicit though they will be founded on judgment and policy rather than on logic.\bigskip
-
-
-Example Certification Authorities: CAs are trusted to certify a key only after proper steps 
-have been taken to identify the principal that owns it.
-
-\end{frame}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
 
 \end{document}