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?

  • $\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
    Commented Oct 5, 2019 at 11:46

3 Answers 3


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.

  • $\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
    Commented 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$ Commented 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
    Commented Oct 5, 2019 at 15:55

Work in progress!!!

I am adding a new answer to complete my previous unsatisfactory answer. The reason why the answer is unsatisfactory is that it's somewhat incomplete:

  • It explains AKEs from the perspective of a specific instantiation. This was also noted in comments under the question and the answer. It also leaves aside some important considerations for AKE security.
  • The intended abstraction uses a framework that can be confusing and lead to misleading conclusions if not familiar. I don't think the abstraction itself is wrong; it has been used to analyze protocols like TLS or other unilateral AKEs.

Below, I'll try to improve the answer by completing it and using a more common framework to explain AKEs.

Intuitively, an AKE is a protocol allowing two parties to establish a fresh shared secret key after a run of the protocol. Furthermore, an AKE should guarantee "authentication". This is usually understood as a guarantee of the peer's identity, but as we'll see later, we typically require more. Before developing more on the goals of an AKE, let's talk about the adversarial model.

Basic adversarial model

The fundamental adversarial model is due to the seminal work of Bellare and Rogaway, which captures some minimum requirements that one might intuitively expect but whose formalism takes some work. Also, it's been a while since a paper recommended MD5 as a building block. In the BR model, we consider an adversary with full control over the network to be allowed to reveal some established session keys and compromise long-term ones (like signing keys and/or shared secrets). Finally, we consider that any user may engage in several AKE runs (in parallel) with the same or many other peers. Each of these runs creates unique local objects that we refer to as sessions.

Basic security goals

  • Key indistinguishability: We require that a freshly establish session key is indistinguishable from random. The emphasis on freshness is to disallow trivial wins. Indeed, recalling the adversarial capabilities, they can reveal session keys or even impersonate users once they have revealed their long-term keys. So we can't hope to protect these keys.
  • Explicit authentication: When an AKE finishes, and some party believes they have established a session with a peer, there must be a peer session participating in the AKE. Note: BR does not use the notion of "explicit authentication", which was introduced in the later development of the BR model.

More on authentication

Explicit authentication, as stated before, guarantees more than "entity authentication". It can be roughly understood as "entity authentication" & "key authentication". Some protocols are only designed for "implicit authentication", where the existence of the peer session is only implicitly guaranteed through key derivation, the secrecy of the key and the use of that key in other protocols. Once a session establishes a secret key, only the intended peer must be able to establish the same key later (one session for each peer).

Advanced goals

  • Forward secrecy: Established session keys must remain secure even if long-term secrets are later compromised. This is a basic requirement by today's standards.
  • Resistance against key compromise impersonation: a KCI attack is when the compromise of a long-term key allows the attack to impersonate anyone towards the compromised entity. Naturally, we expect the attacker to impersonate the entity to anyone once the long-term secrets are compromised, but this doesn't imply KCI attacks can't be prevented.
  • Resistance against identity misbinding attacks: An attacker should not cause two entities to conclude a session with a shared key but with different views of who their peers are. For example, Bob and Alice establish a shared key, but Bob thinks he is talking to Charlie.

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

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

Your Answer

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

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