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

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.

On Fri, Feb 15, 2019 at 5:50 AM Mark D. Baushke <mdb at juniper.net>
wrote:
>
> Yegor Ievlev <koops1997 at gmail.com> writes:
>
> > Also, how are default moduli shipped with OpenSSH for use in
> > diffie-hellman-group-exchange-sha1/sha256 chosen?
>
> You should never use a moduli file shipped by any distribution. Ever.
>
> If you are using OpenSSH, then look at the moduli command to generate
> the moduli file.
>
> That said, you may generate P and Q any way you like, the goal is that
> they be safe primes with a small generator G.
>
> Although, if you follow the suggestions in RFC4419, you will more than
> likely select a safe-prime G,Q,P set where the generator g will not
> generate a proper Q-Ordered subgroup of P. This is a big deal if you
> want to do FIPS certification. That said, NIST still has not come out
> with a change to their standards to allow safe-primes in the general
> case for Diffie-Hellman key exchange, so FIPS certification folks will
> normally need to avoid configuring
> diffie-hellman-group-exchange-sha1/sha256 in any case.
>
> > Are they chosen randomly by developers
>
> The should be generated randomly at an appropriate distributions of
> sizes.
>
> > or are they chosen for security properties?
>
> That they are not fixed moduli is the security property itself.
>
> > If they are random, why not use moduli from RFC 7919 instead, like
> > Mozilla recommends?
>
> Ahh... a philosophical debate? The selection of primes generated
> based on digits of PI (RFC3526) vs E (RFC7919) (Euler's Number)?
>
> https://www.pleacher.com/mp/mhumor/epi.html
> https://www.reddit.com/r/math/comments/na7ua/pi_vs_e_debate/
> https://math.unca.edu/sites/default/files/documents/2013ParsonsLecture.pdf
> https://www.maa.org/press/maa-reviews/the-great-pie-debate
>
> If you like using fixed moduli, then you may wish to look at RFC8268.
> Of the proposed additions, OpenSSH provides these:
>   diffie-hellman-group14-sha256
>   diffie-hellman-group16-sha512
>   diffie-hellman-group18-sha512
>
> The purpose of the RFC4419 moduli is that it is desirable that a state
> actor is not able to pre-generate the list of all possible
> public/private values on the RFC3526 or RFC7919 published primes.
>
> By generating a large set of primes for your own server, you make it a
> lot harder for anyone to be able to eavesdrop on your conversation.
>
> Using a very large subgroup such as is provided by safe-primes means
> that the number of public values sent over the wire will also be very
> large.
>
> Selection of an improper generator means that that there may be more
> than one solution for the public X that is passed. Generally, it is
> considered that this will reduce the size of the effective security of
> the prime moduli by one bit. So, a G,P where P is 2048 bits may find
> that if G^X mod P does not generate a Q-ordered subgroup, the security
> of the exchange may only be 2047 bits. The way to validate this is to
> use G^Q mod P and if the value is 1, then G is a proper Q-ordered
> subgroup.
>
> The alternative to using RFC4419 would be to generate a provable primes,
> but then you have the issue of selection of Q and G properly and the
> client would not necessarily know the value Q being used as it is not
> sent by the RFC4419 protocol as it is assumed Q may be calculated by the
> client if they need it.
>
> I hope this answers your question.
>
>         -- Mark

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 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, Darren Tucker 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.
is there a document somewhere that gives simple instructions on how to do this 
(as opposed to digging them out of a large RFC that covers lots of other stuff)

ideally a simple script that could be run.

Can this be something that is set to run in the background (heavily niced) and 
then switch in when completed? or would that cause grief with existing keys in 
use?

David Lang
> With those caveats, you are also welcome to add the appropriate
> ssh-keygen commands to your startup scripts.
>
>

On Fri, 2019-02-15 at 15:57 +1100, Darren Tucker wrote:
> 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.
One way of handling this, at least if the moduli generation was nicely
interruptable, is that distros ship a file, e.g. /etc/ssh/moduli.dist
but by some mean (init script, systemd unit, maybe even sshd itself) a
daemon that does calculation of new moduli values is started whenever
/etc/ssh/moduli (no ".dist") isn't found.

Since some systems (workstations, notebooks) may shutdown frequently,
this would need to be interruptable and resumable... e.g. on SIGINT/HUP
that calculation service would write to /var/lib/ssh/moduli.tmp or
whatever.


With new config options, distros/admin could even pre-set which and how
many groups are calculated.


Cheers,
Chris.