juju generates/uses insecure ssh keys

[Loïc Gomez]

Juju generates insecure RSA 2048 client SSH keys in .local/share/juju/ssh/juju_id_rsa.

We need juju to use RSA keys of at least 4096 bits length or even better, use ed25519 keys.

[John A Meinel (jameinel)]

I don't think it is problematic to move, but as far as I can tell NIST
considers 2048 secure through 2030, and only really recommends going to
3072 beyond that point. (At least, that is what I can pull from:
https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
).

On Thu, May 19, 2022 at 3:16 AM Loïc Gomez <email address hidden>
wrote:

> Public bug reported:
>
> Juju generates insecure RSA 2048 client SSH keys in
> .local/share/juju/ssh/juju_id_rsa.
>
> We need juju to use RSA keys of at least 4096 bits length or even
> better, use ed25519 keys.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: canonical-is
>
> ** Description changed:
>
> Juju generates insecure RSA 2048 client SSH keys in
> .local/share/juju/ssh/juju_id_rsa.
>
> We need juju to use RSA keys of at least 4096 bits length or even
> - better, use ed25519 256+ keys.
> + better, use ed25519 keys.
>
> ** Tags added: canonical-is
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1974132
>
> Title:
> juju generates/uses insecure ssh keys
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1974132/+subscriptions
>
>

[Loïc Gomez (kotodama)]

Indeed, but NIST is only listing minimum sizes, not recommended ones ;)
We need to use 4096bits when we can, 2048 makes sense only when using outdated software.

For example, Debian is recommending 4096 keys since 2010:
https://lists.debian.org/debian-devel-announce/2010/09/msg00003.html

See this article for more details: https://danielpocock.com/rsa-key-sizes-2048-or-4096-bits/

[Harry Pidcock (hpidcock)]

We did some work in this area around ed25519, I proposed we remove RSA2048 in 3.1.

[Loïc Gomez (kotodama)]

Nice, thank you!

[Jack Shaw (jack-shaw)]

Hi there

To quickly resolve this, we have decided to make the quick change of sticking with rsa upping the bit count to 3072 for new keys.

A future piece of work may introduce Ed25519, ECDSA, etc. as well as resolving this relevant issue:
https://bugs.launchpad.net/juju/+bug/1951597

[Jack Shaw (jack-shaw)]

https://github.com/juju/juju/pull/15089

[Loïc Gomez (kotodama)]

Hi Jack,

Thank you, that's a start!
Is there any rationale behind not bumping key size to 4096 bits altogether?

[Jack Shaw (jack-shaw)]

Yes. It came down to a question of balancing security and speed. 3072 bits was found to be sufficiently secure whilst not having too great an impact on performance

Ideally, as you point out, Ed25519 would be used. However, Ed25519 isn't currently considered FIPS compliant so we would need a way switch back to RSA or to ECDSA.

This, combined with concerns expressed here https://bugs.launchpad.net/juju/+bug/1951597 lead us to the conclusion that SSH keys could do with being reworked to

However, Juju is currently in feature-freeze until 3.1 is released. Perhaps this is something we will see in 3.2

[Junien F (axino)]

@jack-shaw : Hello ! Would you have a link to how the performance measurements were done ? Thanks !

[Jack Shaw (jack-shaw)]

https://webmasters.stackexchange.com/questions/84838/performance-4096-bit-rsa-key-compared-to-2048-bit-rsa-key

As `openssl speed rsa2048 rsa3072 rsa4096` reveals, on a relative basis, 4096 bit is a significantly slower

However, upon further investigation the impact this will have on Juju's UX is quite minimal. And Debian recommending 4096 does provide a compelling reason to match, so I think on second viewing we will go straight up to 4096

[Loïc Gomez (kotodama)]

Wonderful news, thank you!

[Harry Pidcock (hpidcock)]

rsa4096 seems like a good compromise until we can properly design ways to configure juju to generate keys with different ciphers/parameters.