10

I'm looking for help determining acceptable Diffie Hellman (DH) Groups for specific IPSec IKE and ESP Encryption Algorithms. The goal is to choose DH groups that provide adequate protection for the keys to be used by selected Encryption Algorithms while avoiding unnecessary overhead from DH groups that are poorly-matched (slower DH groups without added security benefits?).

The specific Encryption Algorithms I can choose from include AES-CBC and AES-GCM with various key lengths (128, 256, etc).

The Diffie Hellman Groups I can select from include

  • 14 = 2048-bit MODP group
  • 19 = 256-bit random ECP group
  • 20 = 384-bit random ECP group
  • 21 = 521-bit random ECP group
  • 24 = 2048-bit MODP Group with 256-bit Prime Order Subgroup

Some of the information I'm reading from Network Security vendor documents suggest the use of DH Elliptic Curve (EC) groups like 19, 20, and 21 over the other groups.

  • Cisco "When possible, use ... the ... ECDH groups"
  • Check Point
    • "elliptic curve Diffie-Hellman groups ... provide better performance"
    • "groups described in RFC 5114 (Group 24 ...) are NOT RECOMMENDED for use"
  • IBM "Guideline: If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 5,14,19,20, or 24. If you are using encryption or authentication algorithms with a key length of 256 bits or greater, use Diffie-Hellman group 21."

I am particularly confused about when to use Groups 14 and 24. Is 24 stronger than 21? I'm thinking 21 is stronger even though the DH group number 24 is higher (just a group identifier number). I also am thinking that group 19 is stronger than 14 - not because of the higher number, but because of the stronger EC algorithm? Based on some of my reading, it appears that the groups ordered by strength from low to high would be something like 14, 24, 19, 20, 21 - meaning that if available, the ECP groups 19,20,21 should be preferred over both 14 and 24?

These crypto discussions can easily lead to advanced math and I'm hoping to avoid that as much as possible - please use the most basic explanations or simplest math possible.

4 Answers 4

7

Update 21 Oct 2017. I found some useful info in RFC 5114 under Section 4 "Security Considerations". Based on this recommendation, we can consider DH Groups 14 and 24 as too weak to protect AES 128 Symmetric Keys - this leaves DH Groups 19 through 21 ECP as the minimum acceptable Diffie Hellman groups for generating AES symmetric keys (128 bit and higher).

When secret keys of an appropriate size are used, an approximation of the strength of each of the Diffie-Hellman groups is provided in the table below. For each group, the table contains an RSA key size and symmetric key size that provide roughly equivalent levels of security. This data is based on the recommendations in [NIST80057].

GROUP SYMMETRIC RSA
1024-bit MODP with 160-bit Prime Subgroup 80 1024
2048-bit MODP with 224-bit Prime Subgroup 112 2048
2048-bit MODP with 256-bit Prime Subgroup 112 2048
192-bit Random ECP Group 80 1024
224-bit Random ECP Group 112 2048
256-bit Random ECP Group 128 3072
384-bit Random ECP Group 192 7680
521-bit Random ECP Group 256 15360

Group Numbers mapped to DH algorithm names from RFC 5114 "IKE" Section.

NAME NUMBER
1024-bit MODP Group with 160-bit Prime Order Subgroup 22
2048-bit MODP Group with 224-bit Prime Order Subgroup 23
2048-bit MODP Group with 256-bit Prime Order Subgroup 24
192-bit Random ECP Group 25
224-bit Random ECP Group 26
256-bit Random ECP Group 19
384-bit Random ECP Group 20
521-bit Random ECP Group 21

I was able to find some pairing suggestions in the strongSwan Security Recommendations document under the "Cipher Selection" heading.

  • "aes128-sha256-modp3072 (AES-CBC-128, SHA-256 as HMAC and DH key exchange with 3072 bit key length)" DH-Group-15 (not available on my device)
  • "aes128gcm16-prfsha256-ecp256 (AES-GCM-128 AEAD, SHA-256 as PRF and ECDH key exchange with 256 bit key length)" DH-Group-19
  • "aes256gcm16-prfsha384-ecp384 (AES-GCM-256 AEAD, SHA-384 as PRF and ECDH key exchange with 384 bit key length)" DH-Group-20

It seems that the pairing recommendations may be loosely based on algorithm strength analysis listed on the Belgian BlueKrypt keylength.com site.

This is the closest I could get to a Diffie-Hellman algorithm pairing recommendation. Please post if you find other reputable sources for selecting well-matched Diffie-Hellman groups for use with IPSec encryption.

2
  • Thank you for pointing this out. So, when using an AES256 key protect it with ECP521? Sadly, Windows 10 1703 "Set-VpnConnectionIPsecConfiguration" does not support this configuration. I wonder what the harm of therefore using AES256~ECP256?
    – pcunite
    Commented Dec 27, 2018 at 6:03
  • Hello @pcunite, if you can't match one of the recommended pairings, just use the most secure alternative you have available in your system. These listings should help you determine the relative strength of various crypto options.
    – Mister_Tom
    Commented Dec 31, 2018 at 14:13
2

Do not use DH 22,23 and 24. See https://www.rfc-editor.org/rfc/rfc8247#section-2.4

Groups 22, 23, and 24 are MODP groups with Prime Order Subgroups that are not safe primes. The seeds for these groups have not been publicly released, resulting in reduced trust in these groups. These groups were proposed as alternatives for groups 2 and 14 but never saw wide deployment. It has been shown that group 22 with 1024-bit MODP is too weak and academia have the resources to generate malicious values at this size. This has resulted in group 22 to be demoted to MUST NOT. Groups 23 and 24 have been demoted to SHOULD NOT and are expected to be further downgraded in the near future to MUST NOT. Since groups 23 and 24 have small subgroups, the checks specified in the first bullet point of Section 2.2 of "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC6989] MUST be done when these groups are used.

1

Bit late to be commenting on this, but what you've stated is not entirely correct.

useful info in RFC 5114 under Section 4 "Security Considerations

Those considerations apply to the transforms specifically defined within RFC5114. Take a look back at section 3.2 for example:

However, in the case of ECP Diffie-Hellman groups, the format of key exchange payloads and the derivation of a shared secret has thus far been specified on a group-by-group basis. For the ECP Diffie-Hellman groups defined in this document, the key exchange payload format and shared key derivation procedure specified in [RFC4753] MUST be used (with both IKEv2 and IKEv1).

Since three of the transforms defined within RFC5114 use MODP with an ECP prime subgroup, the comments concerning MODP should logically be taken to mean those three transforms alone given section 3.2 clearly spells out that MODP, i.e. solitary MODP, are defined elsewhere and would arguably include their own relevant security consideration sections.

Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306], and the use of MODP groups with IKEv1 is defined in [RFC2409].

RFC5114 doesn't replace RFC4306 or RFC2409 and thus its security considerations section shouldn't be construed to wholly invalidate the use of MODP entirely as the earlier comments and tables suggest. That is not to say that ECP is not better than MODP in some cases, but MODP (DH15+) is also still arguably just as effective as ECP can be, at least for the time being, and depending on your equipment may in fact provide higher performance than ECP. With the exception of DH21, DH15-18 (MODP) can provide reasonably similar security to DH(19-20). See Security Considerations section of RFC3526 for estimated bit strengths for the MODP transforms.

   +--------+----------+---------------------+---------------------+
   | Group  | Modulus  | Strength Estimate 1 | Strength Estimate 2 |
   |        |          +----------+----------+----------+----------+
   |        |          |          | exponent |          | exponent |
   |        |          | in bits  | size     | in bits  | size     |
   +--------+----------+----------+----------+----------+----------+
   |   5    | 1536-bit |       90 |     180- |      120 |     240- |
   |  14    | 2048-bit |      110 |     220- |      160 |     320- |
   |  15    | 3072-bit |      130 |     260- |      210 |     420- |
   |  16    | 4096-bit |      150 |     300- |      240 |     480- |
   |  17    | 6144-bit |      170 |     340- |      270 |     540- |
   |  18    | 8192-bit |      190 |     380- |      310 |     620- |
   +--------+----------+---------------------+---------------------+

Other sources to consider are the:

The latter is the latest revision of the NIST doc that RFC 5114 originally referred to. The following table from page 55, where FFC equals the MODP DH groups and ECC equals the ECP DH groups, should be useful when comparing to RFC5114 and RFC3526.

NIST SP800-57pt1r5 Encryption Comparative Strength Table

2
  • Thank you for providing more detail and security considerations of the "solitary" MODP groups. That is good information to have in this Q&A thread.
    – Mister_Tom
    Commented Jun 3, 2021 at 16:16
  • Could you explain a bit what you mean with "With the exception of DH21"? It looks like 21 is the strongest of the three ECP algorithms?
    – Alex
    Commented Nov 29, 2022 at 14:38
0

I was also looking into DH21, according to this document from Cisco, it is should be even better than DH19:

Deciding Which Diffie-Hellman Modulus Group to Use

You can use the following Diffie-Hellman key derivation algorithms to generate IPsec security association (SA) keys. Each group has a different size modulus. A larger modulus provides higher security, but requires more processing time. You must have a matching modulus group on both peers.

If you select AES encryption, to support the large key sizes required by AES, you should use Diffie-Hellman (DH) Group 5 or higher. IKEv1 policies do not support all of the groups listed below.

To implement the NSA Suite B cryptography specification, use IKEv2 and select one of the elliptic curve Diffie-Hellman (ECDH) options: 19, 20, or 21. Elliptic curve options and groups that use 2048-bit modulus are less exposed to attacks such as Logjam.

For IKEv2, you can configure multiple groups. The system orders the settings from the most secure to the least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.

  • 14—Diffie-Hellman Group 14: 2048-bit modular exponential (MODP) group. Considered good protection for 192-bit keys.
  • 15—Diffie-Hellman Group 15: 3072-bit MODP group.
  • 16—Diffie-Hellman Group 16: 4096-bit MODP group.
  • 19—Diffie-Hellman Group 19: National Institute of Standards and Technology (NIST) 256-bit elliptic curve modulo a prime (ECP) group.
  • 20—Diffie-Hellman Group 20: NIST 384-bit ECP group.
  • 21—Diffie-Hellman Group 21: NIST 521-bit ECP group.

You must log in to answer this question.

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