1

I understand how DH key exchange is vulnerable to a MITM attack.

When Alice sends Bob g, p and her public key, if she also sent a value H that was a hashing of the values g,p, and public key all concatenated together, could she and Bob then have a phone call where they verify that H is the same value for both of them, and then be confident that they each have the same values for g, p, and the public key?

I realize that the main point of DH key exchange is so that anonymous parties can exchange a key and that a manual step like this in some ways completely misses the point of DH key exchange.

Still, would this work?

Improve this question
1
  • If you can verify your public key through a trusted channel then you can prevent MitM. But usually it's more convenient to use a long term key for that (which can be a DH key as well). Authenticating DH keys in some way is common. For example DHE_RSA in SSL signs it with the RSA key.
    – CodesInChaos
    Aug 14, 2013 at 15:39

1 Answer 1

Reset to default
1

Alice would not have to send the hash value over the wire; instead, Bob must recompute the hash value on his side, based on the values he received, and then compare the hash value with an authoritative source (the phone call).

This works. It is easy to see if we consider it in two steps:

  1. In the presence of Diffie-Hellman, a Man-in-the-Middle attack requires the attacker to put his own DH public key in lieu of that from Alice or Bob (a MitM is a double-impersonation, so the attacker must do the substitution twice). It suffices for Bob to "make sure" that what he received is indeed what Alice sent to detect such a substitution. Bob can phone Alice and spell out, over the phone line, the DH public key he received (which includes the DH group parameters p and g, and the actual DH public key from Alice ga mod p).

  2. Instead of spelling out the three big integers (that would be more than 1500 hexadecimal characters), Alice and Bob can simply use the hash of the values. As long as the hash function is second-preimage resistant, verifying the hash value is as good as verifying the complete public key.

This method is exactly what happens with SSH. The first time you connect to an hitherto unknown SSH server, you get something like this:

The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?

At this point, you are supposed to phone the sysadmin of the intended server to check the hash value (or check it against some any other authoritative source, which depends on the context). This is exactly what you suggest. The SSH client then records the public key from the server, so that no such question is needed for subsequent connections.

Improve this answer

You must log in to answer this question.

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