Okay this is how I understood it according to this:

  • Alice $A$ establishes a connection to $KDC$ and prepares for session key Exchange $k_{ses}$
  • $A$ encrypts the request with her key $k_A(A, B)$ meaning "need a session key to communicate with Bob $B$"
  • $KDC$ decrypts the message, genereates $k_A(k_{ses}, k_B(A, k_{ses}))$ and sends it to $A$
  • $A$ decrypts the messages and got now $k_{ses}$ the session key and the other part $k_B(A, k_{ses})$ she cannot decrypt (only $B$ kan due to $k_B$).
  • $A$ forwards the $k_B(A, k_{ses})$ message to $B$
  • $B$ decrypts $kB(A, k_{ses})$ and now knows he is talking to $A$ over the key $k_{ses}$

In my slides there is an attack described - the Key Confirmation Attack - which does look like this:

enter image description here

The thing here is now that I am not sure how this is supposed to work. This could only work if $RQST(ID_A, ID_B)$ (I'm sorry for the diverse notation) was not encrypted. This attack cannot work if the request was encrypted by Alice in the first place.

So, are there a few things mixed up or what am I missing?

Oscar cannot produce $k_A(A, O)$ – the requesting message to generate a session key for communication $A$ to $O$ – since he does not have the key of Alice.


1 Answer 1


$ID_a, ID_b, ID_o$ are public information

  1. Oscar sends to $KDC$ a legitimate (encrypted) request to communicate with Alice: $RQST(ID_o,ID_a)$
  2. Oscar gets $Y_o, Y_a$
  3. Oscar sends $Y_a, Y_o$ back to Alice.

Alice cannot tell if she got $Y_b$ or $Y_o$, that's the problem. So, I would say the order of $ID_o$ and $ID_a$ are mixed up in the slide. It would be clearer if it was $RQST(ID_o, ID_a)$ instead of $RQST(ID_a, ID_o)$.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.