# Why send HMAC in reverse direction when performing verified DH with downgrade protection?

The purpose of this procedure is that Alice and Bob perform a verified Diffie-Hellman key exchange. It goes like this:

1. Alice sends her supported signature schemes to Bob. It just says "supported schemes". I suppose signature schemes are meant.
2. Bob selects a signature scheme.
3. Alice chooses `a` and sends `A = g^a mod p` and `Sig_Alice(A)` to Bob.
4. Bob chooses `b` and sends `B = g^b mod p` and `Sig_Bob(B)` to Alice.
5. They calculate `K = g^(a*b)` as usual.
6. Alice sends the HMAC of all messages up to this point to Bob. I suppose this HMAC is sent over the encrypted channel because `K` has already been calculated. I have no idea whether only the messages Alice sent are meant or whether the ones she received are included, too.
7. Bob sends the HMAC of all messages up to this point to Alice. Again, probably over the encrypted channel.

I understand why Alice sends the HMAC of her messages to Bob: To make sure Bob actually received all the signature schemes she supports. It might be that there is a man-in-the-middle who removed all the secure signature schemes so Bob had to choose a non-secure one where the MitM can quickly fake their respective signatures so he can establish an encrypted channel between him and Alice and another one between him and Bob.

But what is the purpose of Bob sending the HMAC over his messages to Alice? What can Alice ever learn from that HMAC? If there is a MitM who faked a weak choice by Bob towards Alice, he has to already have been able to fully impersonate Bob in `4.`, so he knows `K` and therefore sending the HMAC over the encrypted channel never poses any difficulty to the MitM.

Am I overlooking something? Do you know the answers to the questions I uttered in `6.`? Do `6.` and `7.` happen an parallel? It doesn't look like it in the graphic provided in the lecture where for `1.`, `3.`, and `6.` an arrow goes from Alice to Bob and for `2.`, `4.`, and `7.`, an arrow goes from Bob to Alice. I don't understand why `4.` and `3.` aren't swapped. Why would Bob wait for an answer from Alice?

• They actually compute `H(g^(a*b))` where `H` is some hash or other key derivation scheme that is also part of the "scheme" used. Oct 2, 2017 at 7:21

1. Regarding your remark at `1.`: Schemes might also mean different DH schemes, for example different groups or generators. This includes different prime fields or even elliptic curves.
2. As for your main question: Until Bob sends the message in `7.` Alice does not know that Bob knows the shared secret. An adversary might have just replayed a previous B from Bob including the signature. Alice will calculate K and think that she is talking to Bob but he was not involved at all. This is often overlooked because we usually assume that the K will be used after the key agreement and that it will somehow be obvious if the other party does not have it. The general idea here is to make sure that both sides have seen exactly the same conversation. See here.
3. Regarding your question in `6.`: If Alice sends a MAC over all the messages some nonce needs to be added otherwise Bob can just return the same message in `7.` so they probably mean something like "all received" or "all sent". As people pointed out in the comments this is nonsense as long as Bob has to send a MAC over all messages including the MAC he received from Alice in `6.`. (Thanks!)
4. I don't see an obvious reason not to swap `3.` and `4.` either.
• Regarding your 3rd point: I think you should think about this again, briefly. If we assume that those HMACs are over all messages (both sent and received), then no nonce is needed because from Alice's perspective, we know that `A` acts as a nonce, that it influences the HMAC Alice sends, and we also know that Bob's reply in `7.` must be affected by the HMAC Alice sent in `6.`. Therefore, iff the HMAC Alice sends to Bob covers `3.` and iff the HMAC Bob sends back covers the HMAC Alice sent, Alice knows that she actually talks to Bob interactively. Oct 1, 2017 at 23:37