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@xxxxxxxxxxx> wrote: > > On Sat, 26 May 2018, Christian Weisgerber wrote: > > > >> On 2018-05-25, Yegor Ievlev <koops1997@xxxxxxxxx> 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@xxxxxxxxxxx > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
