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. – dandavis Sep 28 '17 at 20:54
  • @dandavis My proposed alternative doesn't require pre-shared secrets either. – UTF-8 Sep 28 '17 at 21:04
  • hmm, what does "already ... have exchanged their PKs in a secure way, why doesn't Alice just send" mean? – dandavis Sep 28 '17 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. – UTF-8 Sep 28 '17 at 21:10

If you use the partners static authentication key for encrypting a session key, then you have no forward secrecy. Once this key is ever compromised (which is not unlikely since it is a long term static key) all communications can be decided after the fact.

You do not have this risk with a DH established session key and you only need a keypair for authentication not for decryption.

  • It seems so obvious now. Thank you. But can you tell me why the scheme doesn't encrypt the messages the communication parters exchange for DH? It seems to me that it'd make attacking DH harder. – UTF-8 Sep 28 '17 at 22:29
  • 1
    It would be possible, and in fact it was discussed for defending against logjam style attacks or postquantum times that additional protection can make sense. I guess it is not done in most schemes from a cryptographic point of elegance. If one method is strong enough it does not seem to require further protection. Besides it should be avoided to use keys for multiple purposes, so if the public keypair is used for authentication it's better not used for decryption as well. I can't say if that is good or bad, overall. – eckes Sep 28 '17 at 23:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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