2
$\begingroup$

I am reading some articles about key exchange. I know classic key exchange, such as Diffie-Hellman key exchange. This type of algorithm is vulnerable to man-in-the-middle attack. However, when using a digital signature algorithm, this attack is invalid.

So, does authenticated key exchange consist of classic key exchange and a digital signature algorithm? Who can tell me?

Improve this question
$\endgroup$
1
  • $\begingroup$ Authenticated key exchange can surely be constructed from a regular key exchange and digital signature. What the current answers fail to mention is that there are schemes that combines authenticity of digital signature and confidentiality of key exchange into a single algorithm (e.g. MQV). $\endgroup$
    – DannyNiu
    Oct 5, 2019 at 11:46

2 Answers 2

Reset to default
2
$\begingroup$

One way to understand this is through a rather abstract and constructive viewpoint, abstracting away specifics.

As you mentioned, a DH key exchange needs to be done in an authenticated manner otherwise man-in-the-middle attacks become possible. In other words, we needs the communication to happen on a authenticated channel.

How do we get an authenticated channel? One way is to use digital signatures. They would allow to verify that the message comes from the legitimate sender. However we still have a problem, the verification keys needs to be transmitted somehow and so far we only have an insecure channel.

In order to resolve this problem, we send digital signatures parameters over an authenticated channel that is obtained by using certificates. If we trust certification authorities, we have indeed an authenticated channel.

Everything put together in a constructive way:

1) Using certificates we construct an authenticated channel that allows exchange of digital signature parameters

2) Using digital signatures, we construct an authenticated channel that allows key-exchange(D.H).

3) Using key exchange results we could also construct a secure channel.

Improve this answer
$\endgroup$
3
  • $\begingroup$ The devil is in the details. Signing the data sent in a DH key exchange (which is a possible reading of 2) is unsatisfactory: a capture can be replayed, and the adversary in the replay will pass the authentication. If further that adversary managed to obtain one party's session secret (e.g. in a test session), then confidentiality of the shared key obtained by DH is lost too. $\endgroup$
    – fgrieu ♦
    Oct 5, 2019 at 15:14
  • $\begingroup$ @fgrieu I agree with your observations. It is true that what I described was more of a "single use" secure key exchange. Or a multiple use but then I am using a stronger notion of authentication than usually(I include replay protection as well). In the case of replay, how does the adversary break the established channel? If i am not mistaken, a replay will be of the form $(g^x, \sigma(g^x))$, this is not enough to recover the secret key. $\endgroup$
    – Marc Ilunga
    Oct 5, 2019 at 15:45
  • $\begingroup$ llunga: I'm assuming that after a first session, Alice reveals her secret $x$ (thus compromising the shared secret of that first session, which was a test one; and with that, the confidentiality of any data that shared secret encrypted). That single leak of Alice makes it possible for an adversary to then not only indefinitely impersonate her in further sessions, but also know the shared secret in such further session. That's bad. A robust Authenticated Key Exchange recovers from past leaks that did not compromise the long-term private key. $\endgroup$
    – fgrieu ♦
    Oct 5, 2019 at 15:55
-1
$\begingroup$

Yes, for example in SSL peers identify each other by exchanging certificate. - each peer verifies cerfiticate that received other peer. - If verificatioin is end successfully, client start diffie-hellman by send client's DH-parameter

that is example of authenticated key exchange

Improve this answer
$\endgroup$
1
  • $\begingroup$ What's described does not result in an authenticated key exchange! It is still vulnerable to a MitM!! $\endgroup$
    – fgrieu ♦
    Oct 5, 2019 at 15:13

Your Answer

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

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