openssh unix dev - Feb 2019 - Can we disable diffie-hellman-group-exchange-sha1 by default?

I don't think there is any point to generate so many moduli. Actually,
3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice.

On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net>
wrote:
>
> On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> > I'm not nearly knowledgeable enough in crypto to fully understand
your
> > answer, but I will try. I wonder why moduli are not automatically
> > generated the first time sshd is started though. That would make much
> > more sense than shipping a default moduli file but also asking
> > everyone to replace it with their own.
>
> That was the original intent (and it's mentioned in RFC4419) however
> each moduli file we ship (70-80 instances of 6 sizes)  takes about 1
> cpu-month to generate on a lowish-power x86-64 machine.  Most of it is
> parallelizable, but even then it'd likely take a few hours to generate
> one of each size.  I imagine that'd cause some complaints about
> startup time.
>
> With those caveats, you are also welcome to add the appropriate
> ssh-keygen commands to your startup scripts.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

I disable everything except curve25519 on my servers and clients (if
they only need to connect to my servers).

On Fri, Feb 15, 2019 at 7:59 AM Yegor Ievlev <koops1997 at gmail.com>
wrote:
>
> I don't think there is any point to generate so many moduli. Actually,
> 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice.
>
> On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at
dtucker.net> wrote:
> >
> > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at
gmail.com> wrote:
> > > I'm not nearly knowledgeable enough in crypto to fully
understand your
> > > answer, but I will try. I wonder why moduli are not automatically
> > > generated the first time sshd is started though. That would make
much
> > > more sense than shipping a default moduli file but also asking
> > > everyone to replace it with their own.
> >
> > That was the original intent (and it's mentioned in RFC4419)
however
> > each moduli file we ship (70-80 instances of 6 sizes)  takes about 1
> > cpu-month to generate on a lowish-power x86-64 machine.  Most of it is
> > parallelizable, but even then it'd likely take a few hours to
generate
> > one of each size.  I imagine that'd cause some complaints about
> > startup time.
> >
> > With those caveats, you are also welcome to add the appropriate
> > ssh-keygen commands to your startup scripts.
> >
> > --
> > Darren Tucker (dtucker at dtucker.net)
> > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
(new)
> >     Good judgement comes with experience. Unfortunately, the
experience
> > usually comes from bad judgement.

On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> I don't think there is any point to generate so many moduli. Actually,
> 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice.
NIST SP 800-57 Part 1, on which the current group size selection code
is based, puts a 4k group at a little over 128 bits of security.  This
is why we generate larger groups (and request them, when using 192 and
256 bit ciphers).

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

That doesn't seem to be the case. See
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
(5.6.1 Comparable Algorithm Strengths)

On Fri, Feb 15, 2019 at 8:28 AM Darren Tucker <dtucker at dtucker.net>
wrote:
>
> On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> > I don't think there is any point to generate so many moduli.
Actually,
> > 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice.
>
> NIST SP 800-57 Part 1, on which the current group size selection code
> is based, puts a 4k group at a little over 128 bits of security.  This
> is why we generate larger groups (and request them, when using 192 and
> 256 bit ciphers).
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.