[EXTERNAL] Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa)

[Morgan, Iain (ARC-TN)[InuTeq, LLC]]

On 11/6/22, 20:01, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+iain.morgan=nasa.gov at mindrot.org on behalf of djm at mindrot.org> wrote:

    On Mon, 7 Nov 2022, Darren Tucker wrote:

    > On Mon, 7 Nov 2022 at 00:51, Job Snijders <job at openbsd.org> wrote:
    > [...]
    > > Perhaps now is a good time to make Ed25519 the default when invoking
    > > ssh-keygen(1) without arguments?
    > 
    > I don't think so.  Outside of DSA (which is REQUIRED in RFC4253 but is
    > considered weak these days), RSA keys are the most widely supported
    > key type and thus most likely to work in any given situation, which
    > makes them an appropriate default.  If you know this is not the case
    > for your environment, that's what "-t" is for.

    I don't mind using defaults to apply a little nudge towards better
    algorithms. OpenSSH has supported ed25519 keys for almost a decade,
    and RFC 8709 has been a standard for a couple of years.

    So I'm cautiously supportive of doing this.

This could be an issue for environments which have to comply with FIPS 140-2, which does not permit ed25519.  In such environments, using -t with ssh-add would work on a per-user basis, but users are so used to the current behaviour that I suspect it would be rather disruptive.

Having said that, by the time such environments move to a version of OpenSSH which implements this proposed change, FIPS 140-3 validated cryptographic modules will hopefully be in place.  I haven't looked over FIPS 140-3, but I recall seeing something that indicated ed25519 might be permitted under it.  If that is true, and various requirements get updated to reflect that, it could be a non-issue.

-- 
Iain