3

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?

Improve this question
4
  • pubkey schemes need no pre-shared secrets, which would enable simpler/faster symmetric encryption.
    – dandavis
    Sep 28, 2017 at 20:54
  • @dandavis My proposed alternative doesn't require pre-shared secrets either.
    – UTF-8
    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?
    – dandavis
    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.
    – UTF-8
    Sep 28, 2017 at 21:10

1 Answer 1

Reset to default
3

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.

Improve this answer
2
  • 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, 2017 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, 2017 at 23:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .