openssh unix dev - Sep 2023 - [patch] ssh-keygen(1): generate Ed25519 keys when invoked without arguments

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

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

On 04.09.23 16:43, Joseph S. Testa II wrote:
> 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."
[...]
> 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.
If what you want is an "improvement for the community at large", you 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230904/c090eef1/attachment.p7s>

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