1
$\begingroup$

Suppose I wanted to add explicit key confirmation to Diffie-Hellman key exchange, would the following scheme be secure?

  1. Alice selects a random $a$ and sends $g^a \mod p$ to Bob

  2. Bob selects a random $b$, computes the shared secret $S = (g^a \mod p)^b$

  3. Bob computes two keys using HKDF ($H(k, m)$ denotes the HMAC of message $m$ using key $k$):

    • Compute $k = H(salt, S)$
    • Compute $k_1 = H(k, CTX || 0)$ and $k_2 = H(k, CTX || 1)$
  4. Bob sends $g^b \mod p$, $H(k_1, k_2)$, the salt, and the string CTX to Alice

  5. Alice computes the shared secret $S = (g^b \mod p)^a$, computes $k_1$ and $k_2$ using HKDF given the salt and the string CTX

  6. Alice computes $H(k_1, k_2)$ and verifies whether it's the same as the value that she received from Bob.

$\endgroup$

1 Answer 1

4
$\begingroup$

The major thing missing from Diffie-Hellman is that it provides no protection from someone running a man-in-the-middle attack. Your changes don't actually do anything to prevent that.

That is, suppose Eve was between Alice and Bob; when Alice sends the first message to Bob, Eve intercepts the message, and performs the exchange with Alice. At the same time, Eve forwards her own exchange to Bob. If Alice and Bob were attempting to perform this exchange to create secret keys, well, they will really share keys with Eve; when Alice sends a message, Eve will receive that encrypted message, decrypt it with the key she shares with Alice, examine it, and then encrypt it with the key she shares with Bob, and forwards it. That way, Eve sees all the traffic between Alice and Bob without being aware of it.

There is nothing that this key confirmation does that makes this any more difficult for Eve; she can compute $H(k_1, k_2)$ just as well as Alice and Bob, and so she will be able to impersonate Bob to Alice (and impersonating Alice to Bob).

Now, if the question was "is it secure if we don't have to worry about man-in-the-middle", the answer is "well, straight Diffie-Hellman is secure in that scenario; your additions don't appear to have made anything worse".

$\endgroup$
4
  • $\begingroup$ Thanks for looking at it, @poncho. Yes, I was assuming that man-in-the-middle was not an issue in the question. $\endgroup$
    – herrfz
    Feb 7, 2014 at 16:20
  • $\begingroup$ @herrfz: The sole additional information you're providing an evesdropper is $H(k_1, k_2)$; given that the only way to attack that is either to brute force it, or to have a Rainbow table, and the shared secret $S$ is too large for either; this doesn't give an evesdropper any additional edge. $\endgroup$
    – poncho
    Feb 7, 2014 at 16:47
  • $\begingroup$ @herrfz man-in-the-middle is always issue. $\endgroup$
    – catpnosis
    Feb 7, 2014 at 20:52
  • 1
    $\begingroup$ @catpnosis I'm totally aware of that. In my application we've achieved authentication through some other means, which I intentionally excluded from the question. I really just want to focus on the "explicit key confirmation" issue. $\endgroup$
    – herrfz
    Feb 7, 2014 at 21:26

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.