Diffie-Hellman (DH) is a key exchange algorithm that allows two devices to establish a shared secret over an unsecured network without having shared anything beforehand. Diffie-Hellman is used in IKE, TLS, SSH, SMIME, and likely other protocols. When used in VPNs, it is used in the in IKE or Phase1 part of setting up the VPN tunnel.

In modern implementations of IKEv1, the following DH groups are available for use, Group 1, 2, 5 & 7. In modern implementations of IKEv2, the following DH Groups are available for use, Group 1, 2, 5, 14, 19, 20, 21, & 24.

**Note:** IKEv1 should be avoided unless absolutely necessary. DH Group 7 should also not be used.

There are multiple Diffie-Hellman Groups that can be configured in an IKE policy on a Cisco IOS & ASA.

###### Diffie Hellman Groups

DH Group # | Group Description | RFC | Recommendation |
---|---|---|---|

1 | 768 bit modulus | RFC 2049 | AVOID Available for use in IKEv1 & IKEv2 |

2 | 1024 bit modulus | RFC 2049 | AVOID Available for use in IKEv1 & IKEv2 |

5 | 1536 bit modulus | RFC 3526 | AVOID Available for use in IKEv1 & IKEv2 |

7 | EC2N group over GF[2^163] | IETF Draft | AVOID Available for use in IKEv1 |

14 | 2048-bit modulus | RFC 3526 | MINIMUM ACCEPTABLE Available for use in IKEv2 |

19 | 256-bit random elliptic curve | RFC 5903 | Available for use in IKEv2 |

20 | 384-bit random elliptic curve | RFC 5903 | Available for use in IKEv2 |

21 | 521-bit random elliptic curve | RFC 5903 | Available for use in IKEv2 |

24 | 2048-bit modulus with 256-bit prime order subgroup | RFC 5114 | AVOID Available for use in IKEv2 |

A full list of ALL Diffie-Hellman Groups is here.

Algorithms marked as AVOID do not provide an adequate security against modern threats and should not be used.

AES needs stronger Diffie-Hellman Groups than DES or 3DES. If we were using a modular based key to protect 128-bit AES we would need a key about 3200-bits long and if we were using a modular based key to protect 256-bit AES we would need a key 15400-bits long. That’s not practical, so instead, we are now using elliptic curve Diffie-Hellman Groups. If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 19, 20. If you are using encryption or authentication algorithms with a 256-bit key or higher, use Diffie-Hellman group 21. RFC 5114 Sec 4 states DH Group 24 strength is about equal to a modular key that is 2048-bits long, that is not strong enough to protect 128 or 256-bit AES, so I also mark that as AVOID.

##### References

Brief comparison of RSA and diffie-hellman (public key) algorithm

Cisco – Next-Generation Encryption

How Diffie-Hellman Fails in Practice

IANA – Internet Key Exchange (IKE) Attributes

RFC 2409 – The Internet Key Exchange (IKE)

RFC 3526 – More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

RFC – 3766 – Determining Strengths For Public Keys Used For Exchanging Symmetric Keys

RFC 5114 – Additional Diffie-Hellman Groups for Use with IETF Standards

Why are you recommending avoiding DH group 24?

This can quickly get into real advanced math which is far above my head so I’m not going there but to answer your question.

RFC 5114 Sec 4 states DH Group 24 strength is about equal to a modular key that is 2048-bits long, that is not strong enough to protect 128 or 256-bit AES, so I also mark that as AVOID.

Also check this out.

https://security.stackexchange.com/questions/171418/diffie-hellman-group-matching-to-ipsec-encryption-algorithm