2
$\begingroup$

We know there is a man in the middle vulnerability with unauthenticated DH key establishment. And the way to negate that is to use authenticate the keys used. But what if I only verify the signature of one end. Is there any vulnerability then?

EDIT: To be clear, I am not referring to the fact that the authenticated party does not know who its talking to. I am specifically thinking about a cryptographic vulnerability where someone who does not have control over the machine (of the unauthenticated end) can do some damage.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ If the unauthenticated end's group element does not go into the signature then explicit authentication certainly fails and there could conceivably be an attack based on what DH value the server gets after the adversary has submitted a different group element. $\:$ If the group and generator are not known a-priori and they do not go into the signature then there could conceivably be an attack based on creating a detectable correlation between the DH values. $\;\;\;\;$ $\endgroup$ – user991 May 10 '14 at 21:03
  • $\begingroup$ What kind of an attack though? Does attacker get to do a successful man in the middle? Remember the client is verifying the server's keys. The server is not. So can an attacker really insert himself into the middle? $\endgroup$ – user220201 May 12 '14 at 1:47
  • $\begingroup$ "If the unauthenticated end's group element does not go into the signature then" there is a replay attack against explicit authentication. $\:$ A "... submitted a different group element" attack would either be man in the middle or not need that position. $\:$ An attacker probably can't "really insert himself into the middle", since DH in a generic group wouldn't allow him to do so, which makes it even less likely that there's an attack that doesn't require being a man in the middle. $\;\;\;\;$ $\endgroup$ – user991 May 12 '14 at 2:08
  • $\begingroup$ My previous two sentences also apply to "group and generator are not known a-priori" attacks. $\hspace{.65 in}$ $\endgroup$ – user991 May 12 '14 at 2:12
1
$\begingroup$

…what if I only verify the signature of one end?

Bob would not be able to know if he is looking at a signature by Eve, or if it’s a valid signature coming from Alice. In case if Eve is messing with the exchange, Eve would be able to inject her own (as it is handled non-authenticated) and Eve would be able to verify that it’s Bob on the other end (which boils down to “non-deniability”). Depending on the individual situation, these can be a real neck-breakers.

Is there any vulnerability then?

Yes! As described above, there is a vulnerability in that case because one authenticated party would be “talking” to an non-authenticated other party… whoever that may be. That’s why authentication is regarded to be so important in the realms of cryptography – to detect if Eve is messing with things.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ However, allowing Eve to imitate Alice might not be a security issue, depending on the scenario. Consider Amazon; they, as Bob, don't care who they are talking to, be it Alice or Eve. In this scenario, Bob (Amazon) doesn't check any signatures, because they don't care. Alice is the one who cares that she gives her credit card information to Amazon, and not Eve -- having Alice check Amazon's signature does that. Of course, there are other situations where having both sides authenticate the other is Very Important. $\endgroup$ – poncho Jun 9 '14 at 14:42
  • $\begingroup$ @poncho Thanks for that addition! Indeed, if “whoever that may be” isn’t important for an individual implementation, you can skip it. (To be honest, I imagined that to be a logic deduction… which is why I merely pointed to those “other situations” where skipping the authentication of a single party during a DH key exchange may very well introduce a worst-case scenario. Anyway, thanks for adding your additional pointer… much appreciated.) $\endgroup$ – e-sushi Jun 9 '14 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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