Strange crypto choices

[Damien Miller]

there are more implications to changing key algorithms than KEX
algorithms. If a change is made to the specification, then it might
invalidate all the keys that are out there, this isn't the case with
any other negotiated algorithm,


On Sun, 27 May 2018, Yegor Ievlev wrote:

> I don't think we should wait for a RFC in order to use stronger
> crypto. We already prefer Curve25519 for key exchange without waiting
> for it. So why wait for a RFC in this case?
> 
> On Sun, May 27, 2018 at 5:09 AM, Damien Miller <djm at mindrot.org> wrote:
> > On Sat, 26 May 2018, Christian Weisgerber wrote:
> >
> >> On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote:
> >>
> >> > The defaults for HostKeyAlgorithms option are: [...]
> >> > Why does OpenSSH prefer older and less secure
> >> > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519?
> >>
> >> I asked Markus and Damien about this in the past but honestly don't
> >> remember the answer.  Some of the potential reasons (lack of
> >> standardization, no DNS fingerprint, ...) seem to no longer apply.
> >> I've been wanting to hassle Markus and Damien about this again,
> >> once I run into them in person, but that opportunity hasn't presented
> >> itself yet.
> >
> > Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at
> > https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html
> >
> > Christian is right about our reasoning for the other choices.
> >
> > -d
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>