326 break the encryption unless they have this key.

   326 break the encryption unless they have this key and that the

   327 nonces are fresh each time the protocol is run.

   328 

   329 There might be something mysterious about the nonces, the

   330 random numbers, that are sent around. They need to be

   331 unpredictable and in this way fulfil an important role in

   332 protocols. Suppose

   333 

   334 \begin{enumerate}

   335 \item I generate a nonce and send it to you encrypted with a

   336       key we share

   337 \item you increase it by one, encrypt it under a key I know

   338       and send it back to me 

   339 \end{enumerate}

   340 

   341 \noindent In our notation this would correspond to the 

   342 protocol

   343 

   344 \begin{center}

   345 \begin{tabular}{l@{\hspace{2mm}}l}

   346 $I \to Y:$ & $\{N\}_{K_{IY}}$\\

   347 $Y \to I:$ & $\{N + 1\}_{K_{IY}}$\\

   348 \end{tabular} 

   349 \end{center}

   350 

   351 \noindent What can I infer from this simple exchange:

   352 

   353 \begin{itemize}

   354 \item you must have received my message (it could not just be

   355       deflected by somebody on the network, because the

   356       response required some calculation; doing the

   357       calculation and sending the answer requires the key

   358       $K_{IY}$)

   359 

   360 \item you could only have generated your answer after I send

   361       you my initial message (since my $N$ is always new, it

   362       could not have been a message that was generated before

   363       I myself knew what $N$ is)

   364 

   365 \item if only you and me know the key $K_{IY$, the message

   366       must have come from you

   367 \end{itemize}

   368 

   369 \noindent Even if this does not seem much information I can

   370 glean from such an exchange, it is in fact the basic building 

   371 blocks for establishing some secret or achieving some 

   372 security goal (like authentication).

   373 

   374 While the mutual challenge-response protocol solves already

   375 the authentication problem, there are some problems. One is of

   376 course that it requires a pre-shared secret key. That is

   377 something that needs to be established beforehand. Not all

   378 situations allow such an assumption. For example if I am 

   379 a whistle blower (say Snowden) and want to talk to a

   380 journalist (say Greenwald) then I might not have a secret

   381 pre-shared key. The other problem is that such mutual

   382 challenge-response systems often work in the same system

   383 in the ``challenge mode'' but also in the ``response mode''.

   384 For example if two servers want to talk to each other---they

   385 would need the protocol in response mode, but also if they

   386 want to talk to other servers in challenge mode. Similarly

   387 if you in an military aircraft you have to challenge everybody

   388 you see, in case there is a friend amongst the targets you 

   389 like to shoot, but you also have to respond to any of your

   390 own anti-aircraft guns on the ground. In these situations

   391 you have to be careful to not decode, or answer, your own 

   392 challenge.