On 11/6/22, 20:01, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+iain.morgan=nasa.gov@xxxxxxxxxxx on behalf of djm@xxxxxxxxxxx> wrote:
On Mon, 7 Nov 2022, Darren Tucker wrote:
> On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@xxxxxxxxxxx> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
