RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1012577 - Openssh cryptographic algorithms security
Summary: Openssh cryptographic algorithms security
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.4
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1002711
TreeView+ depends on / blocked
 
Reported: 2013-09-26 16:33 UTC by Nilesh Parmar
Modified: 2019-08-15 03:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1021587 (view as bug list)
Environment:
Last Closed: 2015-09-14 11:37:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Nilesh Parmar 2013-09-26 16:33:33 UTC
Description of problem:

Cloning the bugzilla 'https://bugzilla.redhat.com/show_bug.cgi?id=1010607' which opened for fedora.


1. It is fairly hard to actually find out the exact cryptographic algorithms and their paramters used for a particular ssh session.  ssh -vvvv provides some hints, but you seem to need to already know what's going on to decipher the cryptic debug messages. This should be made a lot easier and more transparent. It should state simply a clearly, for example, that it is doing a Diffie-Hellman key exchange with parameters such and such.

2. For legal reasons, Fedora's openssh comes without elliptic curve cryptography (ECC) support, see bug 319901. It has been argued that this is a bad thing since ECC provides high security efficiently. It has also been argued that this might be a good thing, since constants used in ECC might contain a NSA backdoor (see also http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance). One way or another, the absence of any *option* to use ECC can't be a good thing.

3. Hoever, with ECC disabled, openssh defaults to discrete logarithm Diffie-Hellman (DH) for key exchange. This method uses dh.c:dh_estimate() to compute the group size DH parameter:

/*
 * Estimates the group order for a Diffie-Hellman group that has an
 * attack complexity approximately the same as O(2**bits).  Estimate
 * with:  O(exp(1.9223 * (ln q)^(1/3) (ln ln q)^(2/3)))
 */

int
dh_estimate(int bits)
{

        if (bits <= 128)
                return (1024);  /* O(2**86) */
        if (bits <= 192)
                return (2048);  /* O(2**116) */
        return (4096);          /* O(2**156) */
}


Here the parameter "bits" is max(key size, block size, iv size, mac size), see kex.c:kex_choose_conf(), in the loop before "kex->we_need = need", also note the multiplication by 8 (because we_need is measured in bytes) in the call "nbits = dh_estimate(kex->we_need * 8)" in kexgexc.c:kexgex_client().

Now I do not have the slightest idea what the author of this piece of code is trying to say with the comments (what is q supposed to be, and its relation to the only parameter "bits"? Where do the number 86, 116, 156 come from?) However, I understand that a block cipher with 128 bit key size gives us a 1024 group size.

This is not in line with standard advice about cryptographic key lengths, which states that a 128 bit block cipher should be used with a group size of 3072 bits (192 bits with 7680 bit group size, 256 bits with 15360 bit group size), see http://www.keylength.com/en/compare/ (NIST; others are even more conservative). In fact, while today it practically impossible to break a 128 bit block cipher, it is considered fairly realistic to break a 1024 bit RSA, DSA or DH key.

I ask for a second opinion on my analysis, please. If I am right, dh_estimate() should be changed as follows:

/*
 * Estimates the group order for a Diffie-Hellman group that has an
 * attack complexity approximately the same as O(2**bits).  Estimates
 * are from "Recommendation for Key Management,"
 * Special Publication 800-57 Part 1 Rev. 3, NIST, 07/2012.
 */
int
dh_estimate(int bits)
{

        if (bits <= 128)
                return (3072);
        if (bits <= 192)
                return (7680);
        return (15360);
}

Note that dh.c contains the definition

#define DH_GRP_MAX      8192

which is less than 15360, so this probably has to be changed, and possibly other places have to be changed as a consequence (again there is no useful explanation for this definiton and its interdependences or consequences in the source code). If this cannot be done (perhaps the maximum is mandated by some part of the ssh protocol, or something), "return (4096);" should be replaced instead by "return (8192);"

Version-Release number of selected component (if applicable):
openssh-6.2p2-5.fc19.i686

How reproducible:
always

Steps to Reproduce:
1. ssh -vvvv localhost

Actual results:
...
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
...

Expected results:
...
debug1: kexgex_client: Using discrete logarithm Diffie-Hellman key exchange with 256 bit private key size and 3072 bit group size (we_need*8 = 128)
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<16384) sent
...

Comment 2 RHEL Program Management 2013-10-14 01:54:49 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 7 Jakub Jelen 2015-09-14 11:37:00 UTC
Customer ticket was closed after discussion with reporter so I am closing also this bug to clean up.

tl;dr: The reasons for opening this bug do not apply any more.


Note You need to log in before you can comment on or make changes to this bug.