Zac Brown's Nonsense

Infrequent posts, occasionally useful.

Re: Modernizing SSH Keys

Recently, I’ve been working with a few different services that require an SSH key for authentication. From personal projects hosted on Digital Ocean or coding that I’ve been doing on sourcehut. I forget which one of these services I was working with when I needed to produce a new SSH key that wasn’t my primary one.

I am forever forgetting how to generate an SSH key despite its simple command format:

ssh-keygen -t ... -b ...

I only create them about once every couple of years, usually when I’m bringing up new machines and they need a new client key. However, when I was consulting the instructions from the site on generating keys, it mentioned an algorithm I hadn’t seen before, ed25519. At the time, I didn’t think too much of it. I filed it away in my brain for further investigation.

Today I found myself with some free time and I wanted to do something I should have done long ago - replace my old SSH key with a newer and stronger passphrase. My old key was probably created at least 8 years ago and relatively strong for the time, using RSA w/ 8192 bits. But, sadly, the passphrase was nothing particularly strong - neither long nor nearly as complex as it should’ve been.

Then, I started looking at SSH key generation and what the state of the art is. In my reading, I found that there were two algorithms I didn’t know about:

  • ecdsa - An elliptic curve algorithm. Probably the best known usage of this algorithm is in Bitcoin.
    – It was “broken” by the fail0verflow hacking group when they announced they were able to recover the ecdsa private key used for signing software for Sony’s PlayStation 3. It was later determined that Sony incorrectly implemented the algorithm and kept the variable k constant instead of random.– To be clear, this algorithm is still considered cryptographically secure. Issues noted to date with the algorithm have been in the implementations of it, rather than the algorithm itself.– For a period, at least, this algorithm was used pretty broadly for TLS v1.2 certificates.
  • ed25519 - Another elliptic curve algorithm though using a more modern implementation of “twisted Edwards curves” (don’t ask me, I’m not smart enough to explain it). This algorithm is actually a specific variant of the EdDSA algorithm that combines SHA-512 with Curve25519. The punch line is that it’s intended to be much faster without sacrificing security.

After doing a little reading, it became clear that if you were connecting to modern versions of the OpenSSH server, then you should prefer updating your keys to ed25519. RSA is decidedly legacy at this point and if you’re still using DSA, you should definitely update your keys. If you’re already using ecdsa, move along, there’s nothing you need to do unless you want a faster key.

So on that note, I created the new key:

ssh-keygen -t ed25519

Then I updated my .zpreztorc to load the new id_ed25519 private key instead of my old id_rsa private key.

Then I started out by cataloging all the places I’d need to update my SSH public keys:

  • personal servers - netsvc, networkz, brownhole
  • GitHub
  • GitLab
  • sourcehut
  • Digital Ocean
  • AWS

I’ve just about updated everything at this point. Am I now able to sync harder and faster? Maybe. Mostly this was just about getting a stronger passphrase on my core SSH keys.

Postscript

I should note that RSA is by no means “broken” or a bad choice. If you’re dealing with older installs of OpenSSH, then RSA with at least 4096 bits is the SSH key algorithm of choice.

However, I basically only interact with pretty up to date infrastructure and so I can commit to using the more modern ed25519 algorithm. I am keeping around my old RSA key as a backup, just in case there are machines or services that I forgot to update.