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

I referred to the fact that there is no value for 4096-bit groups at
all. For higher strengths than 128 bits one should probably not use
non-EC crypto at all, as the document suggests.

On Fri, Feb 15, 2019 at 9:19 AM Darren Tucker <dtucker at dtucker.net>
wrote:
>
> On Fri, 15 Feb 2019 at 16:45, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> > 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)
>
> For DH, the "Comparable strengths" table lists L=3072 for 128
bits and
> L=7680 for 192 bits.  To me that puts 4k groups a bit above 128 bits
> and well below 192 bits of security.   What are you referring to?
>
> --
> 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.

Yegor Ievlev <koops1997 at gmail.com> writes:
> I referred to the fact that there is no value for 4096-bit groups at
> all. For higher strengths than 128 bits one should probably not use
> non-EC crypto at all, as the document suggests.
For Diffie-Hellman 4096-bits, running one of the mathematical methods
gives you on the order of 150 bits of security. See RFC 3526 section 8.

For a 190-bits of security, you need a Diffie-Hellman of 8k-bits in
size.

Of course, using a larger Q-ordered subgroup such as we get with
safe-primes helps to increase the computation time needed even beyond
the standard sieve techniques.

The speed of an ECC computation is indeed faster than FFC. However, you
need to assume that you can trust that the standard curves have not been
heavily pre-computed too.

You may wish to visit

    https://safecurves.cr.yp.to/ 

for an interesting view on ECDH and ECDSA technology.

I am given to understand that NIST is going to be considering EdDSA and
things like Curve25519 and Curve448 in the coming year for release.

The other thing happening is the consideration of using paired curves.
Right now that is not a part of the SSHv2 protocol, but the field
continues to get new research.

	-- Mark

> You may wish to visit https://safecurves.cr.yp.to/.
I read this page MANY times, and generally I am also against using
P-256/384/521. However I believe that risk of using non-EC DH under
2048 bits (Logjam) and SHA-1 is higher, and also take speed into
consideration.
> However, you need to assume that you can trust that the standard curves
have not been
heavily pre-computed too.
They may not only be pre-computed, but also chosen to be easy to
pre-compute. See https://bada55.cr.yp.to/vr.html.
>I am given to understand that NIST is going to be considering EdDSA and
things like Curve25519 and Curve448 in the coming year for release.
Are you confusing IETF and NIST? IETF is heavily using these two
curves, but I did not hear about NIST working at including them into
their standards.
>The other thing happening is the consideration of using paired curves. Right
now that is not a part of the SSHv2 protocol, but the field continues to get new
research.
If by paired curves you mean converting the key between Curve25519 and
Ed25519 form, that's generally not considered to be as secure as using
separate keys.

On Fri, Feb 15, 2019 at 11:34 AM Mark D. Baushke <mdb at juniper.net>
wrote:
>
> Yegor Ievlev <koops1997 at gmail.com> writes:
>
> > I referred to the fact that there is no value for 4096-bit groups at
> > all. For higher strengths than 128 bits one should probably not use
> > non-EC crypto at all, as the document suggests.
>
> For Diffie-Hellman 4096-bits, running one of the mathematical methods
> gives you on the order of 150 bits of security. See RFC 3526 section 8.
>
> For a 190-bits of security, you need a Diffie-Hellman of 8k-bits in
> size.
>
> Of course, using a larger Q-ordered subgroup such as we get with
> safe-primes helps to increase the computation time needed even beyond
> the standard sieve techniques.
>
> The speed of an ECC computation is indeed faster than FFC. However, you
> need to assume that you can trust that the standard curves have not been
> heavily pre-computed too.
>
> You may wish to visit
>
>     https://safecurves.cr.yp.to/
>
> for an interesting view on ECDH and ECDSA technology.
>
> I am given to understand that NIST is going to be considering EdDSA and
> things like Curve25519 and Curve448 in the coming year for release.
>
> The other thing happening is the consideration of using paired curves.
> Right now that is not a part of the SSHv2 protocol, but the field
> continues to get new research.
>
>         -- Mark