Should we use IANA groups 14 (MODP), 25, and 26 (ECP)?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

7

$begingroup$

By looking at SonicWall Knowledge Base article Key exchange (DH) Groups Supported – Site to Site VPN:

It appears that our firewall supports DH group 25, and 26. Almost everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t have DH group 24).

Should we use these groups? I don’t understand how the ID of the DH group could be higher – using the same elliptical curve primitive – but use a 224-bit algorithm compared to our current 521-bit algorithm for DH group 21.

DH group 21 is also “only” a 512 bit algorithm compared to DH group 14, which is a 2048 bit algorithm. However I read that DH group 21 is still better than 14, because it uses elliptical curve.

EDIT: I’ve had a technical response vs a mathematical one below. It’s appreciated, but a technical one helps me understand more given that we’re configuring firewalls. The response is

“This group number is decided or is given by the IANA (Internet Assigned Numbers Authority).

The reason for these lower bit ECP groups to have the higher DH group number is that, the practical implementation (using a software code or a hardware chip) of the key creation and exchange mechanism was only available (or working) for 256, 384, 521 bit sizes. and that’s why they were implemented first (in-order group 19, 20 and 21).

with improvements in technology and the methods with which we write the software code or create hardware chips, it allowed us to have working models for 192 and 224 bit Random ECP DH group and hence these were assigned a DH group number later.

Security wise, the 521 bit Random ECP group (DH Group-21) would still be on a higher side compared to 192 or 224 bit ECP group.”

share|improve this question

$endgroup$

migrated from security.stackexchange.com Jan 3 at 19:03

This question came from our site for information security professionals.

  • $begingroup$
    My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
    $endgroup$
    – Mike Ounsworth
    Jan 3 at 15:27

  • $begingroup$
    Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
    $endgroup$
    – thepip3r
    Jan 3 at 16:16

  • $begingroup$
    Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:39

  • $begingroup$
    @thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:40

  • 1

    $begingroup$
    @MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
    $endgroup$
    – poncho
    Jan 3 at 19:38

7

$begingroup$

By looking at SonicWall Knowledge Base article Key exchange (DH) Groups Supported – Site to Site VPN:

It appears that our firewall supports DH group 25, and 26. Almost everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t have DH group 24).

Should we use these groups? I don’t understand how the ID of the DH group could be higher – using the same elliptical curve primitive – but use a 224-bit algorithm compared to our current 521-bit algorithm for DH group 21.

DH group 21 is also “only” a 512 bit algorithm compared to DH group 14, which is a 2048 bit algorithm. However I read that DH group 21 is still better than 14, because it uses elliptical curve.

EDIT: I’ve had a technical response vs a mathematical one below. It’s appreciated, but a technical one helps me understand more given that we’re configuring firewalls. The response is

“This group number is decided or is given by the IANA (Internet Assigned Numbers Authority).

The reason for these lower bit ECP groups to have the higher DH group number is that, the practical implementation (using a software code or a hardware chip) of the key creation and exchange mechanism was only available (or working) for 256, 384, 521 bit sizes. and that’s why they were implemented first (in-order group 19, 20 and 21).

with improvements in technology and the methods with which we write the software code or create hardware chips, it allowed us to have working models for 192 and 224 bit Random ECP DH group and hence these were assigned a DH group number later.

Security wise, the 521 bit Random ECP group (DH Group-21) would still be on a higher side compared to 192 or 224 bit ECP group.”

share|improve this question

$endgroup$

migrated from security.stackexchange.com Jan 3 at 19:03

This question came from our site for information security professionals.

  • $begingroup$
    My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
    $endgroup$
    – Mike Ounsworth
    Jan 3 at 15:27

  • $begingroup$
    Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
    $endgroup$
    – thepip3r
    Jan 3 at 16:16

  • $begingroup$
    Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:39

  • $begingroup$
    @thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:40

  • 1

    $begingroup$
    @MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
    $endgroup$
    – poncho
    Jan 3 at 19:38

7

7

7

0

$begingroup$

By looking at SonicWall Knowledge Base article Key exchange (DH) Groups Supported – Site to Site VPN:

It appears that our firewall supports DH group 25, and 26. Almost everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t have DH group 24).

Should we use these groups? I don’t understand how the ID of the DH group could be higher – using the same elliptical curve primitive – but use a 224-bit algorithm compared to our current 521-bit algorithm for DH group 21.

DH group 21 is also “only” a 512 bit algorithm compared to DH group 14, which is a 2048 bit algorithm. However I read that DH group 21 is still better than 14, because it uses elliptical curve.

EDIT: I’ve had a technical response vs a mathematical one below. It’s appreciated, but a technical one helps me understand more given that we’re configuring firewalls. The response is

“This group number is decided or is given by the IANA (Internet Assigned Numbers Authority).

The reason for these lower bit ECP groups to have the higher DH group number is that, the practical implementation (using a software code or a hardware chip) of the key creation and exchange mechanism was only available (or working) for 256, 384, 521 bit sizes. and that’s why they were implemented first (in-order group 19, 20 and 21).

with improvements in technology and the methods with which we write the software code or create hardware chips, it allowed us to have working models for 192 and 224 bit Random ECP DH group and hence these were assigned a DH group number later.

Security wise, the 521 bit Random ECP group (DH Group-21) would still be on a higher side compared to 192 or 224 bit ECP group.”

share|improve this question

$endgroup$

By looking at SonicWall Knowledge Base article Key exchange (DH) Groups Supported – Site to Site VPN:

It appears that our firewall supports DH group 25, and 26. Almost everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t have DH group 24).

Should we use these groups? I don’t understand how the ID of the DH group could be higher – using the same elliptical curve primitive – but use a 224-bit algorithm compared to our current 521-bit algorithm for DH group 21.

DH group 21 is also “only” a 512 bit algorithm compared to DH group 14, which is a 2048 bit algorithm. However I read that DH group 21 is still better than 14, because it uses elliptical curve.

EDIT: I’ve had a technical response vs a mathematical one below. It’s appreciated, but a technical one helps me understand more given that we’re configuring firewalls. The response is

“This group number is decided or is given by the IANA (Internet Assigned Numbers Authority).

The reason for these lower bit ECP groups to have the higher DH group number is that, the practical implementation (using a software code or a hardware chip) of the key creation and exchange mechanism was only available (or working) for 256, 384, 521 bit sizes. and that’s why they were implemented first (in-order group 19, 20 and 21).

with improvements in technology and the methods with which we write the software code or create hardware chips, it allowed us to have working models for 192 and 224 bit Random ECP DH group and hence these were assigned a DH group number later.

Security wise, the 521 bit Random ECP group (DH Group-21) would still be on a higher side compared to 192 or 224 bit ECP group.”

elliptic-curves diffie-hellman key-exchange finite-field

share|improve this question

share|improve this question

share|improve this question

share|improve this question

edited Jan 14 at 9:15

wahmedBW

asked Jan 3 at 14:10

wahmedBWwahmedBW

384

384

migrated from security.stackexchange.com Jan 3 at 19:03

This question came from our site for information security professionals.

migrated from security.stackexchange.com Jan 3 at 19:03

This question came from our site for information security professionals.

  • $begingroup$
    My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
    $endgroup$
    – Mike Ounsworth
    Jan 3 at 15:27

  • $begingroup$
    Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
    $endgroup$
    – thepip3r
    Jan 3 at 16:16

  • $begingroup$
    Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:39

  • $begingroup$
    @thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:40

  • 1

    $begingroup$
    @MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
    $endgroup$
    – poncho
    Jan 3 at 19:38

  • $begingroup$
    My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
    $endgroup$
    – Mike Ounsworth
    Jan 3 at 15:27

  • $begingroup$
    Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
    $endgroup$
    – thepip3r
    Jan 3 at 16:16

  • $begingroup$
    Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:39

  • $begingroup$
    @thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
    $endgroup$
    – wahmedBW
    Jan 3 at 16:40

  • 1

    $begingroup$
    @MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
    $endgroup$
    – poncho
    Jan 3 at 19:38

$begingroup$
My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
$endgroup$
– Mike Ounsworth
Jan 3 at 15:27

$begingroup$
My understanding is that the only thing that really matters is the size of the prime (n-bit group). I would normally cite NIST or NSA standards, but with the US government shutdown, none of their websites are available. My intuition is that 224-bits and up are considered secure today, so you might as well go with the 224-bit group as it will have slightly better performance than the larger groups.
$endgroup$
– Mike Ounsworth
Jan 3 at 15:27

$begingroup$
Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
$endgroup$
– thepip3r
Jan 3 at 16:16

$begingroup$
Do you control the other end of the site-to-site VPN you’re trying to set up? If so, why don’t you use a very complex pre-shared key? e.g.: M@Sup1rS*cr#tFu33yW(llP$@@w0rd!! or better yet, use a cryptographically secure key generator that’s long…
$endgroup$
– thepip3r
Jan 3 at 16:16

$begingroup$
Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
$endgroup$
– wahmedBW
Jan 3 at 16:39

$begingroup$
Thanks @MikeOunsworth for that, though when you go to DH group 21, it’s 521 bit. DH group 25 is 192 bit, and DH group 26 is 224 bit. So a lower DH group might actually be better? DH group 21 is also “only” a 512 bit algortithm vs DH group 14, which is a 2048 bit algortithm, however I read that DH group 21 is still better than 14, because it uses elliptical curve. It just then seems odd that DH group 25, and 26 use a smaller algortithm, but still use the same methodology ie: ellitpical curve.
$endgroup$
– wahmedBW
Jan 3 at 16:39

$begingroup$
@thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
$endgroup$
– wahmedBW
Jan 3 at 16:40

$begingroup$
@thepip3r We do have a complex PSK, and it is wholly owned by us, however a) we’d like to be as secure as we can b) We’d need to do this for our third parties anyway.
$endgroup$
– wahmedBW
Jan 3 at 16:40

1

1

$begingroup$
@MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
$endgroup$
– poncho
Jan 3 at 19:38

$begingroup$
@MaartenBodewes: actually, they use the ephemeral DH plus other public information; however, in IKEv2, they do not stir in the preshared keys. In IKEv1, they did (when doing preshared key authentication), but that meant (among other things) they had to change how they computed keys depending on the authentication method
$endgroup$
– poncho
Jan 3 at 19:38

2 Answers
2

active

oldest

votes

8

$begingroup$

It appears that our firewall supports DH group 25, and 26. Almost
everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t
have DH group 24).

Should we use these groups?

NO, stick to groups 19-21 if possible!


According to the linked resource, DH group 25 is a prime-based 192-bit elliptic curve and group 26 is a prime-based 224-bit elliptic curve. These provide a security level of 96 and 112-bit respectively, that is the best known attack will require about $2^{96}$ or $2^{112}$ curve operations. I suppose these curves were standardized as enough people complained they can’t computationally or by bandwidth or storage afford to use group 19 and the probably did so after 19-21 were standardized.

Now compare this to the groups 19, 20 and 21 which use 256-, 384- and 512- bit elliptic curves which respectively offer 128, 192 and 256-bit security. This is much better at a minor cost of performance. If you really can’t afford to use these groups for performance reasons, then the 224-bit group should be fine, as its security is comparable to 2048-bit classic DH / RSA and the 192-bit group is risky as its security could be broken by a sufficiently determined attacker with sufficient funding, usually this is attributed to nation-state attackers.

DH group 21 is also “only” a 512 bit algorithm compared to DH group
14, which is a 2048 bit algorithm. However I read that DH group 21 is
still better than 14, because it uses elliptical curve.

Group 14 uses classic finite-field diffie-hellman, i.e. $g^xbmod p$ for a 2048-bit prime $p$. Because this operation exposes so much structure, there are attacks that are more efficient than the generic ones, which is all that works against elliptic curves. These attacks are so good, that a 2048-bit prime modulus for DH has roughly a 112-bit security level, which roughly corresponds to a 224-bit elliptic curve, e.g. group 26.

Also note that due to these more scalable attacks, group 1 is actually breakable, even by academics and group 2 which has a 80-bit security level due to its 1024-bit modulus has a decent chance of being breakable by a determined attack with sufficient funding. Also due to the nature of these attacks, it is sufficient if the attacker once does one big pre-computation for the parameter set and can then break individual DH instances very easily, think 1 week of pre-computation to solve each instance in 90 seconds afterwards.

share|improve this answer

$endgroup$

  • 1

    $begingroup$
    I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
    $endgroup$
    – Maarten Bodewes
    Jan 9 at 14:23

4

$begingroup$

Note: I am not familiar with each of the named DH groups (“group 21”, “group 25”, etc) but to my knowledge none of them are broken, so this answer assumes that all groups of the same bit-strength have equivalent security.

DH vs ECDH

Traditional Diffie-Hellman (DH) is based on reversing multiplications / exponents on very large numbers (formally called the Discrete Logarithm problem). This is where you see group sizes like 2048-bit.

Elliptic Curve Diffie-Hellman (ECDH) is based on the mathematical problem of point multiplication on elliptic curves. This is where you see group sizes like 224-bit. Because of the added complexity of doing multiplications on elliptic curves rather than straight integers, ECDH can get the same security using much smaller numbers.

Here is a comparison of security levels:

Table comparing security levels of DH and ECDH

From that table, 2048-bit DH is the same security level as 224-bit ECDH, and was estimated to be ~112 bits of security whenever NIST put together that table. So according to that, you could get away with a 2048/224 bit DH/ECDH group, but 3072/256 bit would be more conservative.

Pros / Cons

For the same security level (say DH 2048 vs ECDH 224) the ECDH will get you better performance (faster, less server load, etc) simply because the numbers to multiply are smaller. So if you have the choice, go for an ECDH group, and go for the smallest one that meets your security needs — if you are doing “normal” e-commerce type things, then a 256-bit ECDH group will be more than enough.

share|improve this answer

$endgroup$

    Your Answer

    StackExchange.ifUsing(“editor”, function () {
    return StackExchange.using(“mathjaxEditing”, function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [[“$”, “$”], [“\\(“,”\\)”]]);
    });
    });
    }, “mathjax-editing”);

    StackExchange.ready(function() {
    var channelOptions = {
    tags: “”.split(” “),
    id: “281”
    };
    initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

    StackExchange.using(“externalEditor”, function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using(“snippets”, function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: ‘answer’,
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: “”,
    imageUploader: {
    brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
    contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: “.discard-answer”
    ,immediatelyShowMarkdownHelp:true
    });

    }
    });

    draft saved
    draft discarded

    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66249%2fshould-we-use-iana-groups-14-modp-25-and-26-ecp%23new-answer’, ‘question_page’);
    }
    );

    Post as a guest

    Required, but never shown

    2 Answers
    2

    active

    oldest

    votes

    2 Answers
    2

    active

    oldest

    votes

    active

    oldest

    votes

    active

    oldest

    votes

    8

    $begingroup$

    It appears that our firewall supports DH group 25, and 26. Almost
    everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t
    have DH group 24).

    Should we use these groups?

    NO, stick to groups 19-21 if possible!


    According to the linked resource, DH group 25 is a prime-based 192-bit elliptic curve and group 26 is a prime-based 224-bit elliptic curve. These provide a security level of 96 and 112-bit respectively, that is the best known attack will require about $2^{96}$ or $2^{112}$ curve operations. I suppose these curves were standardized as enough people complained they can’t computationally or by bandwidth or storage afford to use group 19 and the probably did so after 19-21 were standardized.

    Now compare this to the groups 19, 20 and 21 which use 256-, 384- and 512- bit elliptic curves which respectively offer 128, 192 and 256-bit security. This is much better at a minor cost of performance. If you really can’t afford to use these groups for performance reasons, then the 224-bit group should be fine, as its security is comparable to 2048-bit classic DH / RSA and the 192-bit group is risky as its security could be broken by a sufficiently determined attacker with sufficient funding, usually this is attributed to nation-state attackers.

    DH group 21 is also “only” a 512 bit algorithm compared to DH group
    14, which is a 2048 bit algorithm. However I read that DH group 21 is
    still better than 14, because it uses elliptical curve.

    Group 14 uses classic finite-field diffie-hellman, i.e. $g^xbmod p$ for a 2048-bit prime $p$. Because this operation exposes so much structure, there are attacks that are more efficient than the generic ones, which is all that works against elliptic curves. These attacks are so good, that a 2048-bit prime modulus for DH has roughly a 112-bit security level, which roughly corresponds to a 224-bit elliptic curve, e.g. group 26.

    Also note that due to these more scalable attacks, group 1 is actually breakable, even by academics and group 2 which has a 80-bit security level due to its 1024-bit modulus has a decent chance of being breakable by a determined attack with sufficient funding. Also due to the nature of these attacks, it is sufficient if the attacker once does one big pre-computation for the parameter set and can then break individual DH instances very easily, think 1 week of pre-computation to solve each instance in 90 seconds afterwards.

    share|improve this answer

    $endgroup$

    • 1

      $begingroup$
      I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
      $endgroup$
      – Maarten Bodewes
      Jan 9 at 14:23

    8

    $begingroup$

    It appears that our firewall supports DH group 25, and 26. Almost
    everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t
    have DH group 24).

    Should we use these groups?

    NO, stick to groups 19-21 if possible!


    According to the linked resource, DH group 25 is a prime-based 192-bit elliptic curve and group 26 is a prime-based 224-bit elliptic curve. These provide a security level of 96 and 112-bit respectively, that is the best known attack will require about $2^{96}$ or $2^{112}$ curve operations. I suppose these curves were standardized as enough people complained they can’t computationally or by bandwidth or storage afford to use group 19 and the probably did so after 19-21 were standardized.

    Now compare this to the groups 19, 20 and 21 which use 256-, 384- and 512- bit elliptic curves which respectively offer 128, 192 and 256-bit security. This is much better at a minor cost of performance. If you really can’t afford to use these groups for performance reasons, then the 224-bit group should be fine, as its security is comparable to 2048-bit classic DH / RSA and the 192-bit group is risky as its security could be broken by a sufficiently determined attacker with sufficient funding, usually this is attributed to nation-state attackers.

    DH group 21 is also “only” a 512 bit algorithm compared to DH group
    14, which is a 2048 bit algorithm. However I read that DH group 21 is
    still better than 14, because it uses elliptical curve.

    Group 14 uses classic finite-field diffie-hellman, i.e. $g^xbmod p$ for a 2048-bit prime $p$. Because this operation exposes so much structure, there are attacks that are more efficient than the generic ones, which is all that works against elliptic curves. These attacks are so good, that a 2048-bit prime modulus for DH has roughly a 112-bit security level, which roughly corresponds to a 224-bit elliptic curve, e.g. group 26.

    Also note that due to these more scalable attacks, group 1 is actually breakable, even by academics and group 2 which has a 80-bit security level due to its 1024-bit modulus has a decent chance of being breakable by a determined attack with sufficient funding. Also due to the nature of these attacks, it is sufficient if the attacker once does one big pre-computation for the parameter set and can then break individual DH instances very easily, think 1 week of pre-computation to solve each instance in 90 seconds afterwards.

    share|improve this answer

    $endgroup$

    • 1

      $begingroup$
      I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
      $endgroup$
      – Maarten Bodewes
      Jan 9 at 14:23

    8

    8

    8

    $begingroup$

    It appears that our firewall supports DH group 25, and 26. Almost
    everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t
    have DH group 24).

    Should we use these groups?

    NO, stick to groups 19-21 if possible!


    According to the linked resource, DH group 25 is a prime-based 192-bit elliptic curve and group 26 is a prime-based 224-bit elliptic curve. These provide a security level of 96 and 112-bit respectively, that is the best known attack will require about $2^{96}$ or $2^{112}$ curve operations. I suppose these curves were standardized as enough people complained they can’t computationally or by bandwidth or storage afford to use group 19 and the probably did so after 19-21 were standardized.

    Now compare this to the groups 19, 20 and 21 which use 256-, 384- and 512- bit elliptic curves which respectively offer 128, 192 and 256-bit security. This is much better at a minor cost of performance. If you really can’t afford to use these groups for performance reasons, then the 224-bit group should be fine, as its security is comparable to 2048-bit classic DH / RSA and the 192-bit group is risky as its security could be broken by a sufficiently determined attacker with sufficient funding, usually this is attributed to nation-state attackers.

    DH group 21 is also “only” a 512 bit algorithm compared to DH group
    14, which is a 2048 bit algorithm. However I read that DH group 21 is
    still better than 14, because it uses elliptical curve.

    Group 14 uses classic finite-field diffie-hellman, i.e. $g^xbmod p$ for a 2048-bit prime $p$. Because this operation exposes so much structure, there are attacks that are more efficient than the generic ones, which is all that works against elliptic curves. These attacks are so good, that a 2048-bit prime modulus for DH has roughly a 112-bit security level, which roughly corresponds to a 224-bit elliptic curve, e.g. group 26.

    Also note that due to these more scalable attacks, group 1 is actually breakable, even by academics and group 2 which has a 80-bit security level due to its 1024-bit modulus has a decent chance of being breakable by a determined attack with sufficient funding. Also due to the nature of these attacks, it is sufficient if the attacker once does one big pre-computation for the parameter set and can then break individual DH instances very easily, think 1 week of pre-computation to solve each instance in 90 seconds afterwards.

    share|improve this answer

    $endgroup$

    It appears that our firewall supports DH group 25, and 26. Almost
    everywhere I’ve seen, they’ve recommended DH group 20-24 (we don’t
    have DH group 24).

    Should we use these groups?

    NO, stick to groups 19-21 if possible!


    According to the linked resource, DH group 25 is a prime-based 192-bit elliptic curve and group 26 is a prime-based 224-bit elliptic curve. These provide a security level of 96 and 112-bit respectively, that is the best known attack will require about $2^{96}$ or $2^{112}$ curve operations. I suppose these curves were standardized as enough people complained they can’t computationally or by bandwidth or storage afford to use group 19 and the probably did so after 19-21 were standardized.

    Now compare this to the groups 19, 20 and 21 which use 256-, 384- and 512- bit elliptic curves which respectively offer 128, 192 and 256-bit security. This is much better at a minor cost of performance. If you really can’t afford to use these groups for performance reasons, then the 224-bit group should be fine, as its security is comparable to 2048-bit classic DH / RSA and the 192-bit group is risky as its security could be broken by a sufficiently determined attacker with sufficient funding, usually this is attributed to nation-state attackers.

    DH group 21 is also “only” a 512 bit algorithm compared to DH group
    14, which is a 2048 bit algorithm. However I read that DH group 21 is
    still better than 14, because it uses elliptical curve.

    Group 14 uses classic finite-field diffie-hellman, i.e. $g^xbmod p$ for a 2048-bit prime $p$. Because this operation exposes so much structure, there are attacks that are more efficient than the generic ones, which is all that works against elliptic curves. These attacks are so good, that a 2048-bit prime modulus for DH has roughly a 112-bit security level, which roughly corresponds to a 224-bit elliptic curve, e.g. group 26.

    Also note that due to these more scalable attacks, group 1 is actually breakable, even by academics and group 2 which has a 80-bit security level due to its 1024-bit modulus has a decent chance of being breakable by a determined attack with sufficient funding. Also due to the nature of these attacks, it is sufficient if the attacker once does one big pre-computation for the parameter set and can then break individual DH instances very easily, think 1 week of pre-computation to solve each instance in 90 seconds afterwards.

    share|improve this answer

    share|improve this answer

    share|improve this answer

    edited Jan 9 at 11:53

    Maarten Bodewes

    53.5k677192

    53.5k677192

    answered Jan 3 at 19:33

    SEJPMSEJPM

    28.7k555134

    28.7k555134

    • 1

      $begingroup$
      I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
      $endgroup$
      – Maarten Bodewes
      Jan 9 at 14:23

    • 1

      $begingroup$
      I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
      $endgroup$
      – Maarten Bodewes
      Jan 9 at 14:23

    1

    1

    $begingroup$
    I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
    $endgroup$
    – Maarten Bodewes
    Jan 9 at 14:23

    $begingroup$
    I think this is a perfect technical explanation. I might add that the group is indicated by a group ID. The ID is just a unique number, it doesn’t signify any kind of order or priority. If it did signify a security level of some kinds then the groups 25 and 26 should certainly not have been added.
    $endgroup$
    – Maarten Bodewes
    Jan 9 at 14:23

    4

    $begingroup$

    Note: I am not familiar with each of the named DH groups (“group 21”, “group 25”, etc) but to my knowledge none of them are broken, so this answer assumes that all groups of the same bit-strength have equivalent security.

    DH vs ECDH

    Traditional Diffie-Hellman (DH) is based on reversing multiplications / exponents on very large numbers (formally called the Discrete Logarithm problem). This is where you see group sizes like 2048-bit.

    Elliptic Curve Diffie-Hellman (ECDH) is based on the mathematical problem of point multiplication on elliptic curves. This is where you see group sizes like 224-bit. Because of the added complexity of doing multiplications on elliptic curves rather than straight integers, ECDH can get the same security using much smaller numbers.

    Here is a comparison of security levels:

    Table comparing security levels of DH and ECDH

    From that table, 2048-bit DH is the same security level as 224-bit ECDH, and was estimated to be ~112 bits of security whenever NIST put together that table. So according to that, you could get away with a 2048/224 bit DH/ECDH group, but 3072/256 bit would be more conservative.

    Pros / Cons

    For the same security level (say DH 2048 vs ECDH 224) the ECDH will get you better performance (faster, less server load, etc) simply because the numbers to multiply are smaller. So if you have the choice, go for an ECDH group, and go for the smallest one that meets your security needs — if you are doing “normal” e-commerce type things, then a 256-bit ECDH group will be more than enough.

    share|improve this answer

    $endgroup$

      4

      $begingroup$

      Note: I am not familiar with each of the named DH groups (“group 21”, “group 25”, etc) but to my knowledge none of them are broken, so this answer assumes that all groups of the same bit-strength have equivalent security.

      DH vs ECDH

      Traditional Diffie-Hellman (DH) is based on reversing multiplications / exponents on very large numbers (formally called the Discrete Logarithm problem). This is where you see group sizes like 2048-bit.

      Elliptic Curve Diffie-Hellman (ECDH) is based on the mathematical problem of point multiplication on elliptic curves. This is where you see group sizes like 224-bit. Because of the added complexity of doing multiplications on elliptic curves rather than straight integers, ECDH can get the same security using much smaller numbers.

      Here is a comparison of security levels:

      Table comparing security levels of DH and ECDH

      From that table, 2048-bit DH is the same security level as 224-bit ECDH, and was estimated to be ~112 bits of security whenever NIST put together that table. So according to that, you could get away with a 2048/224 bit DH/ECDH group, but 3072/256 bit would be more conservative.

      Pros / Cons

      For the same security level (say DH 2048 vs ECDH 224) the ECDH will get you better performance (faster, less server load, etc) simply because the numbers to multiply are smaller. So if you have the choice, go for an ECDH group, and go for the smallest one that meets your security needs — if you are doing “normal” e-commerce type things, then a 256-bit ECDH group will be more than enough.

      share|improve this answer

      $endgroup$

        4

        4

        4

        $begingroup$

        Note: I am not familiar with each of the named DH groups (“group 21”, “group 25”, etc) but to my knowledge none of them are broken, so this answer assumes that all groups of the same bit-strength have equivalent security.

        DH vs ECDH

        Traditional Diffie-Hellman (DH) is based on reversing multiplications / exponents on very large numbers (formally called the Discrete Logarithm problem). This is where you see group sizes like 2048-bit.

        Elliptic Curve Diffie-Hellman (ECDH) is based on the mathematical problem of point multiplication on elliptic curves. This is where you see group sizes like 224-bit. Because of the added complexity of doing multiplications on elliptic curves rather than straight integers, ECDH can get the same security using much smaller numbers.

        Here is a comparison of security levels:

        Table comparing security levels of DH and ECDH

        From that table, 2048-bit DH is the same security level as 224-bit ECDH, and was estimated to be ~112 bits of security whenever NIST put together that table. So according to that, you could get away with a 2048/224 bit DH/ECDH group, but 3072/256 bit would be more conservative.

        Pros / Cons

        For the same security level (say DH 2048 vs ECDH 224) the ECDH will get you better performance (faster, less server load, etc) simply because the numbers to multiply are smaller. So if you have the choice, go for an ECDH group, and go for the smallest one that meets your security needs — if you are doing “normal” e-commerce type things, then a 256-bit ECDH group will be more than enough.

        share|improve this answer

        $endgroup$

        Note: I am not familiar with each of the named DH groups (“group 21”, “group 25”, etc) but to my knowledge none of them are broken, so this answer assumes that all groups of the same bit-strength have equivalent security.

        DH vs ECDH

        Traditional Diffie-Hellman (DH) is based on reversing multiplications / exponents on very large numbers (formally called the Discrete Logarithm problem). This is where you see group sizes like 2048-bit.

        Elliptic Curve Diffie-Hellman (ECDH) is based on the mathematical problem of point multiplication on elliptic curves. This is where you see group sizes like 224-bit. Because of the added complexity of doing multiplications on elliptic curves rather than straight integers, ECDH can get the same security using much smaller numbers.

        Here is a comparison of security levels:

        Table comparing security levels of DH and ECDH

        From that table, 2048-bit DH is the same security level as 224-bit ECDH, and was estimated to be ~112 bits of security whenever NIST put together that table. So according to that, you could get away with a 2048/224 bit DH/ECDH group, but 3072/256 bit would be more conservative.

        Pros / Cons

        For the same security level (say DH 2048 vs ECDH 224) the ECDH will get you better performance (faster, less server load, etc) simply because the numbers to multiply are smaller. So if you have the choice, go for an ECDH group, and go for the smallest one that meets your security needs — if you are doing “normal” e-commerce type things, then a 256-bit ECDH group will be more than enough.

        share|improve this answer

        share|improve this answer

        share|improve this answer

        edited Jan 10 at 16:36

        Maarten Bodewes

        53.5k677192

        53.5k677192

        answered Jan 3 at 17:50

        Mike OunsworthMike Ounsworth

        2,1401923

        2,1401923

            draft saved
            draft discarded

            Thanks for contributing an answer to Cryptography Stack Exchange!

            • Please be sure to answer the question. Provide details and share your research!

            But avoid

            • Asking for help, clarification, or responding to other answers.
            • Making statements based on opinion; back them up with references or personal experience.

            Use MathJax to format equations. MathJax reference.

            To learn more, see our tips on writing great answers.

            draft saved

            draft discarded

            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f66249%2fshould-we-use-iana-groups-14-modp-25-and-26-ecp%23new-answer’, ‘question_page’);
            }
            );

            Post as a guest

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Required, but never shown

            Related Post

            Leave a Reply

            Your email address will not be published. Required fields are marked *