Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm looking at a system that uses an unprotected Diffie-Hellman exchange to negotiate a key for the session encryption.

That Diffie-Hellman is not secure against man-in-the-middle attacks is textbook knowledge, but how much harm could an attacker do if he is only able to modify one or both primes in the Diffie-Hellman exchange and is only able to do passive listening on the rest of the conversation ?

I have a gut feeling that the attacker can probably sabotage the resulting encryption key so that passive listening will work, but I can really argue why the original parties wouldn't notice the intrusion.

Any pointers ?

share|improve this question
    
If you modify one or both primes at the beginning Alice and Bob will not get a common secret value, so, in fact they will try to exchange their keys again. Yes you are successfully sabotaging the communication between them in the way that they will never arrive to the "actual secret communication" phase. –  kiBytes Feb 19 at 9:28
    
Suppose Malroy exchanges both primes to be 0 and the implementations on both ends don't properly check for such bad values ? Maybe there are even more clever values to insert so the exchange still works ? –  Gene Vincent Feb 19 at 9:35
    
Zero is not a prime number, so they will never agree on that... –  kiBytes Feb 19 at 9:36
    
Zero is indeed easy to check, but are you sure all implementations do a proper prime check on the values they receive ? I bet not all do. –  Gene Vincent Feb 19 at 9:39
    
The problem you point with the "Zero" is the same as choosing very low prime numbers like "2" and "3", if the implementation is buggy then you can do whatever you want. We could consider that the implementation is so buggy that it doesn't even use the keys and the actual communication is plain text, but I guess that is not the point issued, is it? –  kiBytes Feb 19 at 9:42

1 Answer 1

Let's go with an example, you are MITM.

  1. Alice sends Bob the prime number and the base, ie: p=23, g=5.
  2. But... MITM changes p and g to 29 and 7.
  3. So Bob agrees with Alice using p and g 29 and 7.
  4. MITM man now can't change Bob response so it just send Alice 29 and 7.

Two options now, Alice can reject the 29 and 7 since they are not the original values and begin the negotiation again or Alice sends an acknowledgement to Bob for 29 and 7 values, let's consider the second option, since the first option ends up with no communication.

  1. Alice agrees to use 29 and 7 as new P and G and select a secret number.
  2. MITM now only can look and he will never now the secret number Alice has chosen. He can try to bruteforce, but that can take time and that is not the matter discussed.

So, in this case it doesn't really matter who chooses the prime numbers, in fact they could be public.

(It can actually compromise the communication by choosing very low prime number as 2 and 3 since a brute force attack to these number is actually easy, but I guess most algorithms will force big prime numbers).

As a last note, if the implementation is really buggy (as @GeneVincent suggest) and allow very low prime numbers, then you got it. You can listen the communication easily.

share|improve this answer
    
I doubt that common implementations check for a low bound for the primes. I quickly looked at OpenSSL and I can't specify a low bound for the primes. So they either don't check or use a default value that is applicable for all situations, probably even on embedded devices. So Malroy can probably choose a low prime just within his computational reach for a brute fore. –  Gene Vincent Feb 19 at 9:55
    
Consider that the most probable scenario is the first one where Alice rejects the primes modified by Malroy. –  kiBytes Feb 19 at 9:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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