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: Kamil Dudka <kdudka_at_redhat.com>
Date: Thu, 07 Apr 2016 10:17:08 +0200

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
Received on 2016-04-07

the libssh2 team