openssh unix dev - May 2015 - [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Comment on attachment 2630
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2630
Make the DH-GEX fallback group 4k bit.

Where did this group come from? IMO it would be best to use one of the
standard groups if we're picking another fixed one - logjam attacks
aren't remotely plausible at this length, and doing so avoids any
questions over the group's provenance.

You could use the RFC3526 (ISAKMP) 4096-bit group:
https://tools.ietf.org/html/rfc3526#page-5

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote:
> Hi Folks,
>
> The generator value of 5 does not lead to a q-ordered subgroup which is
> needed to pass tests in
>
>
http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
I pulled revision 2 of this document from here:

https://dx.doi.org/10.6028/nist.sp.800-56ar2

The "FFC Domain Parameter Generation" section does say:

    g is a generator of the cyclic subgroup of GF(p)* of order q,

But i don't see a recommendation of why this matters.  Surely we don't
want the subgroup of order 2, but what is wrong with using a subgroup of
order 2q = p-1?

There's clearly no strong security advantage to the 2q subgroup -- it's
just one bit larger -- but is there an attack that works against the 2q
subgroup that doesn't work against the q subgroup?  If this is a known
concern, i'd be happy with just a pointer to a paper or web page
explaining the risks of the larger group.

otoh, if the goal is just to ensure we have word-for-word compliance
with SP800-56A, then it's clear that choosing a different generator is
the way to go (and without much of a security cost).  but i'd like to
know if there's a reason other than blind-spec-compliance.  Pointers?

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150527/2f8f51cc/attachment.bin>