Man in the Middle Attack to the Diffie Hellman key exchange: g parameter injection variant

Introduction

The Diffie Hellman key exchange protocol [1] normally have the group values (prime p and generator g) defined statically containing a standardized list of values. In this article I will explain what can happen if those values are negotiated dynamically instead of statically from a few standardized values contained on the RFC 3526 [2].

What are the values negotiated via the RFC 3526 ?

RFC 3526 defines a standardized Modular Exponential Groups (MODP) to be used in the Diffie Hellman (DH) key exchange protocol. These values are public but critical for the security, efficiency and success of this protocol.

RFC 3526 provides predefined prime p and generator g for DH groups of various sizes, depending on the security requirements:

• 1536-bit MODP Group (not recommended anymore)
• 2048-bit MODP Group
• 3072-bit MODP Group
• 4096-bit MODP Group
• 6144-bit MODP Group
• 8192-bit MODP Group

Each group specifies:

• prime p: a large safe prime, such that (p-1)/2 is also prime, called a Sophie Germain prime.
• generator g: usually g = 2

The 1536 bit MODP group is not recommended anymore because as the computational capabilities increased, well funded adversaries can run precompute data used on the DH key exchange protocol for each (p, g) pair using the Number Field Sieve Algorithm (NFS) creating big tables of modular logarithms that can afterwards be used to access large number of websites that use that particular MODP group. This attack was already shown on the Logjam Attack paper (2015) [3].

Here is an example of a 6144-bit MODP Group present in the RFC 3526 in hexadecimal format:

p = 0xFFFFFFFF FFFFFFFF C90FDAA2 
      2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6
      3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D
      F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9
      A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411
      7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836
      1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356
      208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08
      CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2
      EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C
      EA956AE5 15D22618 98FA0510
      15728E5A 8AAAC42D AD33170D
      04507A33 A85521AB DF1CBA64
      ECFB8504 58DBEF0A 8AEA7157
      5D060C7D B3970F85 A6E1E4C7
      ABF5AE8C DB0933D7 1E8C94E0
      4A25619D CEE3D226 1AD2EE6B
      F12FFA06 D98A0864 D8760273
      3EC86A64 521F2B18 177B200C
      BBE11757 7A615D6C 770988C0
      BAD946E2 08E24FA0 74E5AB31
      43DB5BFC E0FD108E 4B82D120
      A9210801 1A723C12 A787E6D7
      88719A10 BDBA5B26 99C32718
      6AF4E23C 1A946834 B6150BDA
      2583E9CA 2AD44CE8 DBBBC2DB
      04DE8EF9 2E8EFC14 1FBECAA6
      287C5947 4E6BC05D 99B2964F
      A090C3A2 233BA186 515BE7ED
      1F612970 CEE2D7AF B81BDD76
      2170481C D0069127 D5B05AA9
      93B4EA98 8D8FDDC1 86FFB7DC
      90A6C08F 4DF435C9 34028492
      36C3FAB4 D27C7026 C1D4DCB2
      602646DE C9751E76 3DBA37BD
      F8FF9406 AD9E530E EE5DB382
      F413001A EB06A53E D9027D83
      1179727B 0865A891 8DA3EDBE
      BCF9B14E D44CE6CB ACED4BB1
      BDB7F144 7E6CC254 B3320515
      12BD7AF4 26FB8F40 1378CD2B
      F5983CA0 1C64B92E CF032EA1
      5D1721D0 3F482D7C E6E74FEF
      6D55E702 F46980C8 2B5A8403
      1900B1C9 E59E7C97 FBEC7E8F
      323A97A7 E36CC88B E0F1D45B
      7FF585AC 54BD407B 22B4154A
      ACC8F6D7 EBF48E1D 814CC5ED
      20F8037E 0A79715E EF29BE32
      806A1D58 BB7C5DA7 6F550AA3
      D8A1FBFF 0EB19CCB 1A313D55
      CDA56C9E C2EF2963 2387FE8D
      76E3C046 8043E8F6 63F4860E
      E12BF2D5 B0B7474D 6E694F91 
      E6DCC402 4FFFFFFF FFFFFFFF
      F

g = 0x02

During the TLS handshake, the first steps in the Diffie Hellman Key exchange protocol is to negotiate the DH group to use (e.g. MODP 2048-bit group), that defines the value of the prime p and the generator g.

These values are not secret, but are instead public and standardized.

These two values are important because the strength of the DH depends on the size of the prime p.

The use of standardized parameter groups allows or requires:

Security: The larger the prime p, the harder the discrete logarithm problem, as the problem space increases with the size of the prime. The RFC 3526 ensures well chosen, trusted primes to prevent backdoors.

Interoperability: predefined groups means all compliant system can interoperate without the necessity to generate new prime numbers every time, that is an expensive operation and error prone as the prime has to meet certain requirements such as to be of the form p = 2q+1 where p is prime. Also p should be generated using a verified random process.

The generator should also meet security requirements such as:

• the correct sub group should be of the form that g ^ q = 1 mod p

Mitigating precomputation attacks: when a large number of websites uses the same group, attackers can precompute a database of discrete logarithms (Logjam attack) [3] and dilute the attack cost based on the access to that large number of users, so this is a trade-off that has to be taken into consideration, when the computational technology evolves or faster algorithms are published the minimum MODP security requirements should be reviewed.

Performance: large groups guarantee more security but are slower, as the computation will take more time to complete.

Negotiations on a case by case regarding security requirements allow a better balance of security and efficiency as a security and performance compromise.

What can happen if the prime p and generator g are negotiated dynamically ?

If the prime p and generator g are negotiated dynamically instead of statically via the already mentioned MODP Groups present on the RFC 3526, a MitM attack can inject weak or malicious parameters into the real server, breaking intended security of the DH key exchange protocol.

Here follows some of the malicious parameters that can be injected by a MitM attacker:

Weak prime p: if p is too small (e.g. 512 bits), the discrete log problem becomes easy, and the attacker can compute the shared key in real time using the Logjam Attack [3] by means of a precomputed table of discrete logarithms results using the NFS algorithm.

Composite or non-prime p: if the p is composite the security will depend on the strength of the smaller prime, so the bit security of the p will be much less than intended, and directly proportional to the strength of the smaller prime factor of that composite p.

Generator g set to 1, then:

• at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = 1 ^ a mod p = 1.
• at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = 1 ^ b mod p = 1.
• The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = 1 ^ a mod p = 1 and on Bob side: S = A ^ b mod p = 1 ^ b mod p = 1.

Generator g set to p, then:

• at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = p ^ a mod p = 0.
• at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = p ^ b mod p = 0.
• The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = 0 ^ a mod p = 0 and on Bob side: S = A ^ b mod p = 0 ^ b mod p = 0.

Generator g set to p-1, then:

• at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = (p-1) ^ a mod p = (-1) ^ a mod p = +/- 1 , with the signal depending on the parity of value a.
• at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = (p-1) ^ b mod p = (-1) ^ b mod p = +/- 1 , with the signal depending on the parity of value b.
• The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = (+/-1) ^ a mod p = +/- 1 and on Bob side: S = A ^ b mod p = (+/-1) ^ b mod p = +/-1
• The signal of S will depend on the parity of number (ab). This manipulation will reduce the security to 1 bit of entropy.

MitM attack to the DH key exchange protocol implementation:

In this section is presented a practical implementation of the MitM attack to the DH key exchange protocol with a g parameter injection variant.

Mallory in this example is replacing the URL of the real server.

In a real word scenario the initial communication between the two would need to be downgraded to HTTP and Mallory would need to use a software like Wireshark or mitmproxy to catch the data between the two, change it and send it afterwards to the destiny.

The g and p parameters are being exchanged via REST messages, this example exemplifies the importance of adhering to the standard RFC 3526 [2] to avoid the values to be swapped dynamically by a third party in the middle of the communication channel.

The class diagram of this solution is present at figure 1:

The communication between the client and the server is done via HTTP requests and it is the client that has the initiative on this protocol.

The server exposes three endpoints:

• one to execute the DH key exchange protocol via the POST /keyExchange.
• one to retrieve all the session keys created on the server side via the GET /sessionsData.
• one to perform a secure message exchange with a client after the DH key exchange protocol has been completed via the GET /messageExchange.

The sequence diagram of this attack is shown next, figure 2, it is possible to see in detail the actions that the attacker Mallory is performing to the DH key exchange protocol in the initial POST /keyExchange endpoint and afterwards on the GET/messageExchange itself.

Main results obtained during the attack:

The attack was perform for the different possible scenarios, here are the results:

• For the substitution of g = 1 at the MitM, we got the following result for a given simulation at figure 3:

As we can see the shared secret at the server is equal to 1 and then the derived key material will be derive from the nonce's from the client and the server, that are public, so the security is eliminated.

• For the substitution of g = p at the MitM, we got the following result for a given simulation at figure 4:

• For the substitution of g = p-1 at the MitM, we got the two results for a given simulation, the first one is present at figure 6:

The second result, that is equal to p-1 can also appear for the substitution of g = p-1, being the resulting shared secret non deterministic, with the space result of {-1, 1}, figure 7.

Next follows a quick demo of this attack, video 1, with the client on the left screen, Mallory's fake server in the middle screen and the real server on the right. The client will try to perform the POST /keyExchange first, and as it succeeds, it will latter also perform the GET /messageExchange message, both communications will pass the client verification's, so he remains oblivious of the actions of Mallory the whole time.

All the requests from the client are relayed by the fake Mallory server to the real server, in spite of that, there is no error being triggered by the real server.

This demo is for the injection of the malicious parameter of g = 1 by the MitM. The resulting shared secret key on the server on the right is possible to observe, being equal to 1 as expected.

MitM attack with malicious g parameter injection g = 1 is present at the following link: demo.

How to protect against a MitM attack against the DH key exchange protocol

The MitM attack exposes a critical vulnerability in the original Diffie Hellman key exchange, namely the lack of authentication. While DH key exchange protocol was able to solve very cleverly the problem of establishing a shared secret over an insecure channel, it doesn't verify the identities of the parties involved.

To secure Diffie Hellman against MitM attacks, the messages exchanged between Alice and Bob, namely their public keys A and B, must be authenticated. This ensures that the public keys received truly belong to Alice and Bob, preventing Mallory from replacing her own keys [4].

In the case of the current attack in specific, it is also recommended to not publicly exchange and negotiate the p and g parameters but instead exchange the Diffie Hellman Groups for the Internet Key Exchange present on the RFC 3526 statically via their group identification.

References:

[1] T. Sousa, "Diffie-Hellman Key Exchange Protocol," LinkedIn, June 2025. [Online]. Available: https://www.linkedin.com/pulse/diffie-hellman-key-exchange-protocol-tiago-sousa-tlgpf.

[2] D. Kivinen and H. Krawczyk, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)," IETF RFC 3526, May 2003. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc3526.

[3] D. Adrian et al., "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice," in Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS), Oct. 2015. [Online]. Available: https://weakdh.org/imperfect-forward-secrecy.pdf.

[4] T. Sousa, "Man-in-the-Middle Attack in Diffie-Hellman Key Exchange Protocol," LinkedIn, July 2025. [Online]. Available: https://www.linkedin.com/pulse/man-middle-attack-diffie-hellman-key-exchange-protocol-tiago-sousa-7fdhf.