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/ca5222ea819cc5ed797860070b4c6c1aeeb28420
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.
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
Received on 2016-04-06