Mailing List Archive

[patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa)
Dear all,

Support for using Ed25519 for server and user authentication was
introduced in OpenSSH 6.5. I like the compactness of Ed25519 public
keys.

Perhaps now is a good time to make Ed25519 the default when invoking
ssh-keygen(1) without arguments?

Kind regards,

Job

Index: ssh-keygen.1
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.226
diff -u -p -r1.226 ssh-keygen.1
--- ssh-keygen.1 10 Sep 2022 08:50:53 -0000 1.226
+++ ssh-keygen.1 6 Nov 2022 13:31:19 -0000
@@ -185,7 +185,7 @@ The type of key to be generated is speci
option.
If invoked without any arguments,
.Nm
-will generate an RSA key.
+will generate an ed25519 key.
.Pp
.Nm
is also used to generate groups for use in Diffie-Hellman group
Index: ssh-keygen.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
retrieving revision 1.459
diff -u -p -r1.459 ssh-keygen.c
--- ssh-keygen.c 11 Aug 2022 01:56:51 -0000 1.459
+++ ssh-keygen.c 6 Nov 2022 13:31:21 -0000
@@ -61,12 +61,6 @@
#include "ssh-pkcs11.h"
#endif

-#ifdef WITH_OPENSSL
-# define DEFAULT_KEY_TYPE_NAME "rsa"
-#else
-# define DEFAULT_KEY_TYPE_NAME "ed25519"
-#endif
-
/*
* Default number of bits in the RSA, DSA and ECDSA keys. These value can be
* overridden on the command line.
@@ -252,7 +246,7 @@ ask_filename(struct passwd *pw, const ch
char *name = NULL;

if (key_type_name == NULL)
- name = _PATH_SSH_CLIENT_ID_RSA;
+ name = _PATH_SSH_CLIENT_ID_ED25519;
else {
switch (sshkey_type_from_name(key_type_name)) {
case KEY_DSA_CERT:
@@ -3748,7 +3742,7 @@ main(int argc, char **argv)
}

if (key_type_name == NULL)
- key_type_name = DEFAULT_KEY_TYPE_NAME;
+ key_type_name = "ed25519";

type = sshkey_type_from_name(key_type_name);
type_bits_valid(type, key_type_name, &bits);
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
On Sun, 6 Nov 2022, Job Snijders wrote:

> Perhaps now is a good time to make Ed25519 the default when invoking
> ssh-keygen(1) without arguments?

No.

(Also, the 25519 stuff from DJB is not proper Open Source, and often
not welcome, e.g. in the Azure cloud, SSH keys must be RSA.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
Not proper open source how?

Sent from my iPhone

> On Nov 6, 2022, at 16:14, Thorsten Glaser <t.glaser@tarent.de> wrote:
>
> ?On Sun, 6 Nov 2022, Job Snijders wrote:
>
>> Perhaps now is a good time to make Ed25519 the default when invoking
>> ssh-keygen(1) without arguments?
>
> No.
>
> (Also, the 25519 stuff from DJB is not proper Open Source, and often
> not welcome, e.g. in the Azure cloud, SSH keys must be RSA.)
>
> bye,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> ****************************************************
> /?\ The UTF-8 Ribbon
> ? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
> ? HTML eMail! Also, https://www.tarent.de/newsletter
> ? ? header encryption!
> ****************************************************
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
On Mon, 7 Nov 2022, Darren Tucker wrote:

> On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [EXTERNAL] Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
?On 11/6/22, 20:01, "openssh-unix-dev on behalf of Damien Miller" <openssh-unix-dev-bounces+iain.morgan=nasa.gov@mindrot.org on behalf of djm@mindrot.org> wrote:

On Mon, 7 Nov 2022, Darren Tucker wrote:

> On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
On 07.11.22 05:39, Christoph Anton Mitterer wrote:
> 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.

My .02: The most secu(R)e (as in "Resilient") default would encourage
users to have at least *two* keypairs of different algos at hand.

[.I still remember the day after automated nightly updates had washed a
vendor's panicky "let's disable DSA" into our platforms and I was the
only sysadmin to *also* have an "old-fashioned, unnecessarily huge"
*RSA* pubkey distributed onto the target machines]

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
For what it's worth, the current RSA default is FIPS compliant. Although
NIST included ed25519 in FIPS 186-5 and the public comment period closed
more than two years ago, it's still in draft; 186-4 does not include
ed25519 (it does include ecdsa though, with the curves that OpenSSH already
supports).


Tom.III


On Sun, Nov 6, 2022 at 8:04 PM Damien Miller <djm@mindrot.org> wrote:

> On Mon, 7 Nov 2022, Darren Tucker wrote:
>
> > On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa) [ In reply to ]
The US government ???? approved way to measure "how secure is this key" is
via security strength. NIST SP 800-57 Part 1 Rev. 5 Table 2 (
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
page 54) specifies different ways of comparing algorithms by security
strength.

Curve25519, which ed25519 uses, has an order of 2^252 + ${some_stuff} (
src: https://en.wikipedia.org/wiki/Curve25519 ) which makes it
comparable to a 3072 bit RSA key per the NIST guidelines.

I believe OpenSSH generates 2048 bit RSA keys by default so this would,
technically, be more secure. I make no comments on usability for legacy
clients ;)

Cheers,

Ethan

On Wed, Nov 9, 2022 at 3:21 PM Thomas Dwyer III <tomiii@tomiii.com> wrote:

> For what it's worth, the current RSA default is FIPS compliant. Although
> NIST included ed25519 in FIPS 186-5 and the public comment period closed
> more than two years ago, it's still in draft; 186-4 does not include
> ed25519 (it does include ecdsa though, with the curves that OpenSSH already
> supports).
>
>
> Tom.III
>
>
> On Sun, Nov 6, 2022 at 8:04 PM Damien Miller <djm@mindrot.org> wrote:
>
> > On Mon, 7 Nov 2022, Darren Tucker wrote:
> >
> > > On Mon, 7 Nov 2022 at 00:51, Job Snijders <job@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
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev