# HG changeset patch
# User Christian Urban <christian dot urban at kcl dot ac dot uk>
# Date 1414605752 0
# Node ID c4fa7e8a2ffa5b817038f9040b36363c43b28bb3
# Parent  43629c8c88c62d7ddbfd0954b98ed2da411c2492
updated

diff -r 43629c8c88c6 -r c4fa7e8a2ffa handouts/ho05.pdf
Binary file handouts/ho05.pdf has changed
diff -r 43629c8c88c6 -r c4fa7e8a2ffa handouts/ho05.tex
--- a/handouts/ho05.tex	Wed Oct 29 17:35:41 2014 +0000
+++ b/handouts/ho05.tex	Wed Oct 29 18:02:32 2014 +0000
@@ -434,14 +434,15 @@
 secret key $K_{AB}$ and it contains the correct challenge from
 me, namely $N_A$. So I accept that $E$ is a friend and send
 even back the challenge $N'_A$. The problem is that $E$ now
-starts firing at me and I have no clue what is going on and
-suspect, erroneously, that an idiot must have leaked the
-secret key. I followed in both cases the protocol to the
-letter, but somehow $E$, with my help, managed to disguise as
-a friend. As a pilot, I would rather prefer the designer of
-this challenge-response protocol were a tad smarter. For one
-thing they violated the best practice in protocol design of
-using the same key, $K_{AB}$, for two different
+starts firing at me and I have no clue what is going on. I
+might suspect, erroneously, that an idiot must have leaked the
+secret key. Because I followed in both cases the protocol to
+the letter, but somehow $E$, unknowingly to me with my help,
+managed to disguise as a friend. As a pilot, I would be a bit
+peeved at that moment and would have preferred the designer of
+this challenge-response protocol had been a tad smarter. For
+one thing they violated the best practice in protocol design
+of using the same key, $K_{AB}$, for two different
 purposes---challenging and responding. They better had used
 two different keys. This would have averted this attack and
 would have saved me a lot of trouble.
@@ -492,9 +493,38 @@
 be ``online'' anymore until $A$ actually starts sending messages
 to $B$. $A$ and $S$ can completely on their own negotiate a
 new key. 
+
+The major limitation of this protocol however is that I need
+to trust a third party. And in this case completely, because
+$S$ can of course also read easily all messages $A$ sends to
+$B$. The problem is that I cannot really think of any
+institution who could serve as such a trusted third party. One
+would hope the government would be such a trusted party, but
+in the Snowden-era we know that this is wishful thinking in
+the West, and if I lived in Iran or North Korea, for example,
+I would not even start to hope for this.
+
+The cryptographic ``magic'' of public-private keys 
+seems to offer an elegant solution for this, but as we shall 
+see in the next section, this requires some very clever
+protocol design.
  
 \subsubsection*{Averting Person-in-the-Middle Attacks}
 
+The idea of public-private key encryption is that one can
+make public the key $P^{pub}$ which people can use to
+encrypt messages for me. and I can use my key $P^{priv}$
+to be the only one that can decrypt them. While this sounds
+all good, it relies that people can associate me, for example,
+with my public key. That i snot so trivial as it sounds. 
+For example, if I would be the government, Obama for example, 
+and find out who are the trouble makers, I would publish an
+innocent looking webpage and say I am the New York Times, for 
+example, publish a public key, and then just wait for incoming 
+messages. 
+
+
+
 \bigskip\bigskip
 Keyfobs - protocol