With respect to the authentication protocol outlined on slide 31 of lecture 10, can’t A reply with <K+,K-®> (where K+ and K- are A’s public and private keys respectively)?
I don’t fully understand your question. But if Alice replies with K+ K- ® as mentioned, then that value is R since you are encrypting it with Alice private key, and then decrypting it with Alice public key.
If Alice Replies with K+(K-®) then that is just R as mentioned above. And echoing back just R by itself doesn’t provide any additional protection.
By Alice encrypting R with her private key (K-® ) first and sending that back, and then separately sending the public key, this allows Bob to take Alice’s public key and reverse K-® to get R back out.
The property of Public Key Cryptography is that doing it this way provides authentication that is was indeed alice who signed K-® since only she has K-, and this is proved by using K+, which anyone can use to verify it was Alice who signed it, and only her. Since Bob gets R back out he is satisfied that it is the same person he sent R to in the first place.
This particular example is not perfect (as the next slide shows), but that is the general idea.
I guess my notation wasn’t clear - <K+,K-(Nonce)> is a tuple, made of the values K+ and the cipher text K+(nonce) and is not K+(K-(Nonce)).
aaaah ok, just sending them both back in the same step. Yes in this particular example it’s the same difference.
I suspect showing it being sent separately lends itself better to showing how this situation can be made better to avoid man in the middle attacks. i.e. predistributing keys or using a trusted authority who has the public keys instead of sending it yourself.
If Alice send both encrypted R and her public key together it will be similar to what is in the slides. It just reduces one round of exchange, but still has the same problem.