# What's the purpose of anonymous Diffie-Hellman key exchange + verification?

I attended a lecture where a procedure for solving the problem of passive attackers being able to gain knowledge about the identities of communication partners using an authenticated Diffie-Hellman key exchange was presented.

The solution looks like this: Alice and Bob do a DH key exchange where Alice sends A to Bob and Bob sends B to Alice. They then calculate the secret K as usual. Then, Alice sends Enc_K("Alice", Sig_Alice(A)) to Bob and Bob sends Enc_K("Bob", Sig_Bob(B)) to Alice.

Obviously, this has the property of denying passive attackers to learn the identifies of the communication partners and the property of denying active attackers to impersonate one of the communication partners towards the other one (if everything else like the selection of the random numbers for the key exchange, the encryption and signature functions, the following communication, etc. all is done in a secure way, that is, of course).

When learning about this technique, the question of why the DH key is needed emerged to me. If they already have asynchronous crypto and have exchanged their PKs in a secure way, why doesn't Alice just send a randomly chosen K to Bob? This would mean that the communication can start right away, not only after 2 round-trip times. Going from 2 round-trip times to 0 while making the procedure simpler seems too good to me. So what am I missing?

• pubkey schemes need no pre-shared secrets, which would enable simpler/faster symmetric encryption. Commented Sep 28, 2017 at 20:54
• @dandavis My proposed alternative doesn't require pre-shared secrets either. Commented Sep 28, 2017 at 21:04
• hmm, what does "already ... have exchanged their PKs in a secure way, why doesn't Alice just send" mean? Commented Sep 28, 2017 at 21:07
• @dandavis That no attacker was able to interfere with the exchange of PKs. This is required in both schemes. Of course, no one cares whether the attacker recorded the exchanged PKs (in either scheme) but the attacker must not have prevented the key exchange nor must they have been able to impersonate one communication participant towards the other. Commented Sep 28, 2017 at 21:10