The surprising persistence of RSA keys in SSH

Generally speaking, SSH the protocol and OpenSSH the leading implementation of it have (or have had) four different types of SSH keys: RSA, DSA (which has now been deprecated), ECDSA, and Ed25519, listed here in the order of when they were added to SSH (with Ed25519 being the most recent). Since RSA is the oldest, you might reasonably expect that it was the least used of the three that are still actively supported. Instead it remains extremely common to see RSA keys in use, both old ones and even newly generated ones. There are a number of reasons for this, but a good part of it boils down to that RSA is the universal default key type that every SSH implementation supports, and there are more SSH implementations out there than you might expect.

The small reason is that people often don't change what works, especially in how they authenticate to things (just look at all of the old passwords out there). Existing RSA keypairs work, so many people feel little need to change them. However, this only applies in environments where old people are using old keys (which can include keys used on personal machines and for personal things, like your personal Github account).

Next, there is still a certain amount of SSH helper software out there that doesn't support the full range of SSH key types. Some of it doesn't support Ed25519 keys (which are generally everyone's preferred choice of key types), and some of it only supports RSA keys, not even ECDSA keys. If this sounds impossible and absurd, well, it took until 2017 for Gnome Keyring to support ECDSA keys (cf bug #641082).

Beyond this, not all of the world is OpenSSH (and things that talk to it); there are a variety of additional SSH libraries and full implementations, both in (and for) C and in other languages. These implementations all support RSA, because RSA is effectively the universal key type for SSH (everyone supports it on both the client and server side), but their support of other key types is often spotty. You have to implement one key type and it's going to be RSA; you may not implement more than that. Then once you're in an ecology where some things (either clients or servers) only deal with RSA keys, you start defaulting to RSA keys for safety.

This is how I've wound up with recent RSA keys myself. My iOS to Unix file copy environment could only generate RSA keys on my iOS devices (for whatever reasons), and my Yubikey 4 doesn't support Ed25519 keys (and if I have to pick between RSA and ECDSA, I prefer RSA).

The good news is that support for Ed25519 keys is increasingly common. It will probably never be completely universal, but I'm hoping that an increasing number of programs will feel that they can default to generating Ed25519 keys and then offer people an 'if this doesn't work on your ancient SSH device, pick RSA' option.

PS: Because I looked this up, ECDSA keys were added in OpenSSH 5.7, which had its upstream release in January of 2011 (via). That's less than a decade old so it's probably not surprising that they didn't supplant RSA keys, especially since Ed25519 key support came along only a few years later.

from Hacker News https://ift.tt/2zIIY5j