[patch] ssh-keygen(1): generate Ed25519 keys when invoked without arguments
Job Snijders
Ed25519 public keys being as small as they are is very convenient.
There is an opportunity to nudge the world towards modern algorithms.
I believe choices made in OpenSSH can positively impact the wider
eco-system and industry. I'd like to suggest ssh-keygen to generate an
Ed25519 keypair, if invoked without any arguments.
OpenSSH has supported Ed25519 since version 6.5 (January 2014).
The newly published FIPS 186-5 (February 2023) guidelines approve
the EdDSA algorithms specified in IETF RFC 8032 (January 2017).
At p2k23 Theo de Raadt suggested now (before OpenBSD 7.4 release) is
good timing to consider this change. Is there a reason not to do this?
OK?
Kind regards,
Job
Further reading:
Original Ed25519 paper: https://ed25519.cr.yp.to/ed25519-20110926.pdf
IETF RFC 8032: https://datatracker.ietf.org/doc/html/rfc8032
FIPS 186-5: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
Index: ssh-keygen.1
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.229
diff -u -p -r1.229 ssh-keygen.1
--- ssh-keygen.1 23 Jul 2023 20:04:45 -0000 1.229
+++ ssh-keygen.1 3 Sep 2023 21:29:11 -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.470
diff -u -p -r1.470 ssh-keygen.c
--- ssh-keygen.c 17 Jul 2023 04:01:10 -0000 1.470
+++ ssh-keygen.c 3 Sep 2023 21:29:12 -0000
@@ -61,11 +61,7 @@
#include "ssh-pkcs11.h"
#endif
-#ifdef WITH_OPENSSL
-# define DEFAULT_KEY_TYPE_NAME "rsa"
-#else
-# define DEFAULT_KEY_TYPE_NAME "ed25519"
-#endif
+#define DEFAULT_KEY_TYPE_NAME "ed25519"
/*
* Default number of bits in the RSA, DSA and ECDSA keys. These value can be
@@ -252,7 +248,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:
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Stuart Henderson
> Dear all,
>
> Ed25519 public keys being as small as they are is very convenient.
> There is an opportunity to nudge the world towards modern algorithms.
> I believe choices made in OpenSSH can positively impact the wider
> eco-system and industry. I'd like to suggest ssh-keygen to generate an
> Ed25519 keypair, if invoked without any arguments.
>
> OpenSSH has supported Ed25519 since version 6.5 (January 2014).
> The newly published FIPS 186-5 (February 2023) guidelines approve
> the EdDSA algorithms specified in IETF RFC 8032 (January 2017).
> At p2k23 Theo de Raadt suggested now (before OpenBSD 7.4 release) is
> good timing to consider this change. Is there a reason not to do this?
>
> OK?
Thorsten Glaser
>> OpenSSH has supported Ed25519 since version 6.5 (January 2014).
>amazingly, even Mikrotik finally added support (August 2023)...
>Seems a sane default to me. People can always use -t rsa if needed.
I’d rather not.
Almost all *25519* code in existence is derived from DJB’s which
is labelled as being in the public domain, but lacks a fallback
licence for those jurisdictions where people cannot just waive
copyright (and DJB is notorious in not handing out those). I know
of one independent implementation under GPL, which would therefore
not be a choice.
Thanks,
//mirabilos
--
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)
Jim Knoble
> On Sep 3, 2023, at 15:57, Thorsten Glaser <t.gl...@tarent.de> wrote:
>
> On Sun, 3 Sep 2023, Stuart Henderson wrote:
>
>>> OpenSSH has supported Ed25519 since version 6.5 (January 2014).
>
>> amazingly, even Mikrotik finally added support (August 2023)...
>
>> Seems a sane default to me. People can always use -t rsa if needed.
>
> I’d rather not.
>
This doesn't sound like a problem. In a jurisdiction where public domain is legal, type the code in by hand. Public domain means anyone is free to copy it. Once you type it in, you own the copyright (it's your work), and you can license it under MIT, BSD, whatever.
Or is there a specific jurisdiction that claims that DJB's original copyright somehow overrides that?
Thorsten Glaser
>Or is there a specific jurisdiction that claims that DJB's original
>copyright somehow overrides that?
The Berne Convention kinda does that (copyright is automatic), and
in most of Europe, authors cannot voluntarily relinquish copyright
so all works only enter into the Public Domain on the 1ˢᵗ January
that follows their 70ᵗʰ anniversary of death.
In contrast to works done by employees of the USA government (who
successfully defended their copyright in a European court, whereas
it’s in the PD in the USA automatically), however, with an explicit
dedication like this DJB has no grounds to sue anyone over it. Yet,
it’s, strictly speaking, code under copyright with no licence, which
kinda violates “Integrate good code from any source with acceptable
licenses.” (http://www.openbsd.org/goals.html), plus, commercial
violation of copyright is a felony in some legislations and possibly
might not need the original author to sue.
IANAL, TINLA,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Joseph S. Testa II
Earth have a problem with the open-source implementation of ED25519,
but instead of letting that minority choose to re-implement it when/if
they want to, the rest of the community needs to stall their progress
in improving security."
And isn't the ED25519 code is already there on their machine? So isn't
that itself already a problem for that minority, regardless of whether
or not its used?
Either way, that minority can still use "-t rsa".
I very often see IT personnel and developers simply use the default
options for ssh-keygen. They just don't care/don't know to care.
Switching the default to ED25519 would bring the equivalent security
up from 112-bits to 128-bits (as 2048-bit RSA is equivalent to 112-bits
of symmetric strength), which would be a nice improvement for the
community at large.
--
Joseph S. Testa II
Founder & Principal Security Consultant
Positron Security
Jochen Bern
> What I'm hearing in this thread is: "a minority of people on planet
> Earth have a problem with the open-source implementation of ED25519,
> but instead of letting that minority choose to re-implement it when/if
> they want to, the rest of the community needs to stall their progress
> in improving security."
> options for ssh-keygen. They just don't care/don't know to care.
> Switching the default to ED25519 would bring the equivalent security
> up from 112-bits to 128-bits (as 2048-bit RSA is equivalent to 112-bits
> of symmetric strength), which would be a nice improvement for the
> community at large.
should advocate to have a nonspecific ssh-keygen invocation generate a
keypair for the *two* most useful crypto schemes. I still fondly (not!!)
remember the morning we found that a certain distrib had panicked and
shipped nightly updates to disable the "broken!!" (not quite yet) ECDSA
scheme; I was the only sysadmin here who not only had available, but
also *distributed* his RSA pubkey along with the "more modern" ECDSA one.
(Since I often stumble over systems where it's "RSA or stay out!", I
currently urge people around here to use both 4+k RSA and ED25519. Few
listen, alas. :-/ )
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
Felix Fehlauer
> I very often see IT personnel and developers simply use the default
> options for ssh-keygen. They just don't care/don't know to care.
> Switching the default to ED25519 would bring the equivalent security
> up from 112-bits to 128-bits (as 2048-bit RSA is equivalent to 112-bits
> of symmetric strength), which would be a nice improvement for the
> community at large.
hence a change of the default towards improved security is what is needed.
If one looks long enough for drawbacks one will find some and might
never move forward. Thereby I'd like to express support for the proposed
change despite the discussed questions.
Thorsten Glaser
> I also see the default blindly being used in the majority of cases, hence a
> change of the default towards improved security is what is needed.
The switch here does not increase security. It does decrease acceptance
(which Jochen has confirmed).
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!
****************************************************
Rory Campbell-Lange
> On 9/4/23 16:43, Joseph S. Testa II wrote:
> > I very often see IT personnel and developers simply use the default
> > options for ssh-keygen.
> change of the default towards improved security is what is needed.
Somewhat off topic, but the book "Nudge" by Thaler and Sunstein promotes the idea of "better" defaults. https://en.wikipedia.org/wiki/Nudge_(book
The book is associated with libertarian paternalism, two aspects that are likely to come up in debate about this topic, and by extension the fascinating work on perceptions of risk by Kahneman and Tversky. (I found "The Undoing Project" a good read.)
Libertarian paternalism is an odd mix. The libertarian aspect is described by the authors of Nudge as "...people should be free to do what they like-and to opt out of undesirable arrangements if they want to do so", while they describe paternalism as it being "... legitimate for choice architects to try to influence people's behavior in order to make their lives longer, healthier, and better."
There are some good examples in the book of better defaults providing better outcomes.
Personally I like the idea of making ed25519 keys the default.
Rory
Damien Miller
> On Sun, 3 Sep 2023, Stuart Henderson wrote:
>
> >> OpenSSH has supported Ed25519 since version 6.5 (January 2014).
>
> >amazingly, even Mikrotik finally added support (August 2023)...
>
> >Seems a sane default to me. People can always use -t rsa if needed.
>
> I’d rather not.
>
> Almost all *25519* code in existence is derived from DJB’s which
> is labelled as being in the public domain, but lacks a fallback
> licence for those jurisdictions where people cannot just waive
> copyright (and DJB is notorious in not handing out those). I know
> of one independent implementation under GPL, which would therefore
> not be a choice.
This is irrelevant to the choice of the default algorithm. OpenSSH
includes this code (written by Matt Dempsky, not djb) regardless of
what the default happens to be.
Anyway, Job's change has been committed and the default will be
ed25519 in OpenSSH 9.5.
-d
Thorsten Glaser
>This is irrelevant to the choice of the default algorithm. OpenSSH
>includes
Not everywhere. People can remove that from their builds.
> this code (written by Matt Dempsky, not djb) regardless of
It’s not, it clearly says DJB in the source (e.g. ed25519.c).
>Anyway, Job's change has been committed and the default will be
>ed25519 in OpenSSH 9.5.
I register protest (this will make it even harder to get people
to use RSA keys) but I acknowledge that continuing will not lead
anywhere.
bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Joseph S. Testa II
> On Wed, 6 Sep 2023, Damien Miller wrote:
>
> > This is irrelevant to the choice of the default algorithm. OpenSSH
> > includes
>
> Not everywhere. People can remove that from their builds.
Problem solved.