John S. Denker wrote:
>After the key exchange has taken place, Alice
>and Bob can use the key to set up a tunnel to
>keep their discussions private.  Probably one
>of the first things they will do is exchange
>authentication messages through the newly
>created tunnel.  Thereby Alice can decide
>whether this Bob is the Bob she wanted to
>talk to, as opposed to an impersonator.
>Similarly Bob ought to check Alice's creds.

Exchanging authentication messages through the newly created channel is
not secure: It is vulnerable to man-in-the-middle attacks.

For instance, suppose I do a quantum key exchange to get a session key SK,
set up a channel encrypted using SK, and then do a challenge-response
authentication protocol to check whether the party on the other end of
this channel is the Bob I wanted to talk to.  The resulting protocol
looks like this:
  A<->B: [exchange session key SK using a quantum key exchange]
  A->B:  {N_A}_SK
  B->A:  {sig}_SK,    where sig = {N_A}_{K_B^{-1}}

This protocol is insecure.  A man in the middle can relay messages.
  A<->M: [exchange session key SK using a quantum key exchange]
      M<->B: [exchange session key SK' using a quantum key exchange]
  A->M:  {N_A}_SK
     M->B:  {N_A}_SK'
     B->M:  {sig}_SK',    where sig = {N_A}_{K_B^{-1}}
  M->A:  {sig}_SK
Now Alice thinks she is talking to Bob, when actually Mallet has
insinuated herself into the middle of their communication link.

The problem with doing authentication after creation of the channel is
that the authentication is not bound to the quantum key exchange itself.

The only fix I can see is to somehow authenticate the quantum link used
for the quantum key exchange.  For instance, the quantum key exchange
could be done over an authentic link -- a link where you *know* who is
on the other end, and you have confidence that no one can tamper with
the link or splice themselves in.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to