handouts/ho05.tex
changeset 269 c4fa7e8a2ffa
parent 268 43629c8c88c6
child 270 8f2749152f1e
equal deleted inserted replaced
268:43629c8c88c6 269:c4fa7e8a2ffa
   432 message back to us in the challenge mode (step 4). I happily
   432 message back to us in the challenge mode (step 4). I happily
   433 accept this message---after all it is encrypted under the
   433 accept this message---after all it is encrypted under the
   434 secret key $K_{AB}$ and it contains the correct challenge from
   434 secret key $K_{AB}$ and it contains the correct challenge from
   435 me, namely $N_A$. So I accept that $E$ is a friend and send
   435 me, namely $N_A$. So I accept that $E$ is a friend and send
   436 even back the challenge $N'_A$. The problem is that $E$ now
   436 even back the challenge $N'_A$. The problem is that $E$ now
   437 starts firing at me and I have no clue what is going on and
   437 starts firing at me and I have no clue what is going on. I
   438 suspect, erroneously, that an idiot must have leaked the
   438 might suspect, erroneously, that an idiot must have leaked the
   439 secret key. I followed in both cases the protocol to the
   439 secret key. Because I followed in both cases the protocol to
   440 letter, but somehow $E$, with my help, managed to disguise as
   440 the letter, but somehow $E$, unknowingly to me with my help,
   441 a friend. As a pilot, I would rather prefer the designer of
   441 managed to disguise as a friend. As a pilot, I would be a bit
   442 this challenge-response protocol were a tad smarter. For one
   442 peeved at that moment and would have preferred the designer of
   443 thing they violated the best practice in protocol design of
   443 this challenge-response protocol had been a tad smarter. For
   444 using the same key, $K_{AB}$, for two different
   444 one thing they violated the best practice in protocol design
       
   445 of using the same key, $K_{AB}$, for two different
   445 purposes---challenging and responding. They better had used
   446 purposes---challenging and responding. They better had used
   446 two different keys. This would have averted this attack and
   447 two different keys. This would have averted this attack and
   447 would have saved me a lot of trouble.
   448 would have saved me a lot of trouble.
   448 
   449 
   449 \subsubsection*{Trusted Third Parties}
   450 \subsubsection*{Trusted Third Parties}
   490 $A$ and $S$ need to have come together to share
   491 $A$ and $S$ need to have come together to share
   491 a key, similarly $B$ and $S$. After that $B$ does not need to
   492 a key, similarly $B$ and $S$. After that $B$ does not need to
   492 be ``online'' anymore until $A$ actually starts sending messages
   493 be ``online'' anymore until $A$ actually starts sending messages
   493 to $B$. $A$ and $S$ can completely on their own negotiate a
   494 to $B$. $A$ and $S$ can completely on their own negotiate a
   494 new key. 
   495 new key. 
       
   496 
       
   497 The major limitation of this protocol however is that I need
       
   498 to trust a third party. And in this case completely, because
       
   499 $S$ can of course also read easily all messages $A$ sends to
       
   500 $B$. The problem is that I cannot really think of any
       
   501 institution who could serve as such a trusted third party. One
       
   502 would hope the government would be such a trusted party, but
       
   503 in the Snowden-era we know that this is wishful thinking in
       
   504 the West, and if I lived in Iran or North Korea, for example,
       
   505 I would not even start to hope for this.
       
   506 
       
   507 The cryptographic ``magic'' of public-private keys 
       
   508 seems to offer an elegant solution for this, but as we shall 
       
   509 see in the next section, this requires some very clever
       
   510 protocol design.
   495  
   511  
   496 \subsubsection*{Averting Person-in-the-Middle Attacks}
   512 \subsubsection*{Averting Person-in-the-Middle Attacks}
       
   513 
       
   514 The idea of public-private key encryption is that one can
       
   515 make public the key $P^{pub}$ which people can use to
       
   516 encrypt messages for me. and I can use my key $P^{priv}$
       
   517 to be the only one that can decrypt them. While this sounds
       
   518 all good, it relies that people can associate me, for example,
       
   519 with my public key. That i snot so trivial as it sounds. 
       
   520 For example, if I would be the government, Obama for example, 
       
   521 and find out who are the trouble makers, I would publish an
       
   522 innocent looking webpage and say I am the New York Times, for 
       
   523 example, publish a public key, and then just wait for incoming 
       
   524 messages. 
       
   525 
       
   526 
   497 
   527 
   498 \bigskip\bigskip
   528 \bigskip\bigskip
   499 Keyfobs - protocol
   529 Keyfobs - protocol
   500 
   530 
   501 \subsubsection*{Further Reading}
   531 \subsubsection*{Further Reading}