www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: dh parameter generation still not quite right?

Re: dh parameter generation still not quite right?

From: Will Cosgrove <will_at_panic.com>
Date: Thu, 7 Apr 2016 10:07:16 -0700

There is an outstanding pull request to resolve this security issue in a different way than the initial commit; unfortunately I’m not well versed enough in the intricacies of DH to conclude if it’s a good patch or not.

I did contact Daniel about making the group_order * 8 - 1 change in the SHA1 function the day the security bulletin was posted and he agreed it needed to be done; but apparently no one has actually committed the change. I have submitted a pull request with the original fix ported to the SHA1 method which is identical to the fedora patch.


> On Apr 7, 2016, at 1:17 AM, Kamil Dudka <kdudka_at_redhat.com> wrote:
> On Wednesday 06 April 2016 15:08:41 Cody P Schafer wrote:
>> I was looking into CVE-2016-0787 (bits vs bytes confusion within dh
>> exponent generation) and noted that someone had taken a look at the
>> code and commented on the github commit:
>> https://github.com/libssh2/libssh2/commit/ca5222ea819cc5ed797860070b4c6c1aee
>> b28420
>> After some examination myself, it appears that diffie_hellman_sha1 is
>> vulnerable to the same issue that diffie_hellman_sha256 was vulnerable
>> to, and there are other issues with private exponent generation that
>> should be examined.
> Yes, this seems to be a known issue:
> https://www.libssh2.org/mail/libssh2-devel-archive-2016-02/0029.shtml
> In Fedora we apply the following patch on top of libssh2-1.7.0:
> http://pkgs.fedoraproject.org/cgit/rpms/libssh2.git/tree/CVE-2016-0787.patch?id=2d448ce0
> Daniel, should we apply the patch upstream, too?
> I know there are some outstanding issues reported in the above thread but
> they should IMO not prevent this one-liner from being applied as such.
> Kamil
>> I'm including the comments from github below for posterity:
>> yumkam commented on ca5222e on Feb 23:
>>> Something feels eerily wrong here.
>>> 1) compare diffie_hellman_sha1 and diffie_hellman_sha256; is not there
>>> exactly same problem in sha1 variant? 2) if I was not mistaken, this is
>>> generation of "private exponent"; but "private exponent" need not be as
>>> large as group order! Normal size is "twice as generated key material",
>>> something from 256 bits to 512 bits for usual symmetric algos and key
>>> sizes, see rfc4419 section 6.2 (Private exponent) [1]. That is, it was,
>>> indeed, about 2 times too small before (and still wrong for
>>> diffie_hellman_sha1?), but it is more than 4 times too large now. (Well,
>>> at least later is only performance issue). Disclaimer: I'm not real
>>> cryptographer, but only playing one.
>>> P.S. openssh uses
>>> min(2*max(symmetric_{key,iv,block,mac}_in_bits),p_bits-1)
>> yumkam commented on ca5222e on Feb 23:
>>> Also, for diffie-hellman-group-exchange-*, if p_bits+1 is not multiply of
>>> 8, group_order*8 can be larger than p_bits (by up to 7 bits); thus,
>>> generated group_order*8-1-bit random value x can fail 1 < x < (p-1)/2
>>> test, see rfc4419[2]
>> [1]: https://tools.ietf.org/html/rfc4419#section-6.2
>> [2]: https://tools.ietf.org/html/rfc4419#section-3
>> Checking the code in git today shows the same flaws noted in those
>> comments still exist.
>> _______________________________________________
>> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2016-04-07

the libssh2 team