openssh unix dev - Nov 2022 - [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa)

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.

-- 
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 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.

-d

On Mon, 2022-11-07 at 08:40 +1100, Darren Tucker wrote:
> If you know this is not the case
> for your environment, that's what "-t" is for.
Shouldn't the defaults in general be whatever the most (S)ecure (as in
SSH) is?
Regardless of whether that is RSA, Ed25519 or something else in this
specific case.
 

Any anyone who needs something else can use options to quite easily get
that.


Cheers,
Chris.