# HG changeset patch
# User Christian Urban <christian dot urban at kcl dot ac dot uk>
# Date 1414598842 0
# Node ID e711cfd1ec703da8ae4d28a75ff8a24d376793f1
# Parent  2ce6b7c94763fff1922c4b5e58d433769d3a52c9
updated

diff -r 2ce6b7c94763 -r e711cfd1ec70 handouts/ho05.pdf
Binary file handouts/ho05.pdf has changed
diff -r 2ce6b7c94763 -r e711cfd1ec70 handouts/ho05.tex
--- a/handouts/ho05.tex	Wed Oct 29 15:16:33 2014 +0000
+++ b/handouts/ho05.tex	Wed Oct 29 16:07:22 2014 +0000
@@ -323,7 +323,73 @@
 I leave you to argue that $B$ can be sure to talk to $A$.
 Of course these arguments will depend on the assumptions that
 only $A$ and $B$ know the key $K_{AB}$ and that nobody can
-break the encryption unless they have this key.
+break the encryption unless they have this key and that the
+nonces are fresh each time the protocol is run.
+
+There might be something mysterious about the nonces, the
+random numbers, that are sent around. They need to be
+unpredictable and in this way fulfil an important role in
+protocols. Suppose
+
+\begin{enumerate}
+\item I generate a nonce and send it to you encrypted with a
+      key we share
+\item you increase it by one, encrypt it under a key I know
+      and send it back to me 
+\end{enumerate}
+
+\noindent In our notation this would correspond to the 
+protocol
+
+\begin{center}
+\begin{tabular}{l@{\hspace{2mm}}l}
+$I \to Y:$ & $\{N\}_{K_{IY}}$\\
+$Y \to I:$ & $\{N + 1\}_{K_{IY}}$\\
+\end{tabular} 
+\end{center}
+
+\noindent What can I infer from this simple exchange:
+
+\begin{itemize}
+\item you must have received my message (it could not just be
+      deflected by somebody on the network, because the
+      response required some calculation; doing the
+      calculation and sending the answer requires the key
+      $K_{IY}$)
+
+\item you could only have generated your answer after I send
+      you my initial message (since my $N$ is always new, it
+      could not have been a message that was generated before
+      I myself knew what $N$ is)
+
+\item if only you and me know the key $K_{IY$, the message
+      must have come from you
+\end{itemize}
+
+\noindent Even if this does not seem much information I can
+glean from such an exchange, it is in fact the basic building 
+blocks for establishing some secret or achieving some 
+security goal (like authentication).
+
+While the mutual challenge-response protocol solves already
+the authentication problem, there are some problems. One is of
+course that it requires a pre-shared secret key. That is
+something that needs to be established beforehand. Not all
+situations allow such an assumption. For example if I am 
+a whistle blower (say Snowden) and want to talk to a
+journalist (say Greenwald) then I might not have a secret
+pre-shared key. The other problem is that such mutual
+challenge-response systems often work in the same system
+in the ``challenge mode'' but also in the ``response mode''.
+For example if two servers want to talk to each other---they
+would need the protocol in response mode, but also if they
+want to talk to other servers in challenge mode. Similarly
+if you in an military aircraft you have to challenge everybody
+you see, in case there is a friend amongst the targets you 
+like to shoot, but you also have to respond to any of your
+own anti-aircraft guns on the ground. In these situations
+you have to be careful to not decode, or answer, your own 
+challenge.