> If it was more than five years ago and you generated your SSH key with the default options, you probably ended up using RSA algorithm with key-size less than 2048 bits long.
It's closer to 16 years, for OpenSSH [1].
> Open up your terminal and type the following command to generate a new SSH key that uses Ed25519 algorithm:
> Generate SSH key with Ed25519 key type
That's broken in an amusing way. But speaking of broken things, gnome-keyring didn't support ECC for SSH the last time I've checked (a few years ago), and was/is breaking GPG too [2]. Then there are servers with old systems not supporting Ed25519 (it was added in OpenSSH version 6.5, just in 2014 [3]). The situation with smart card support wasn't quite clear the last I've checked, either.
Besides, ECC was thought to be more resistant to quantum computing attacks, but not anymore (and seems to be an easier target at regular key sizes, actually) [4], so it lost some of the appeal.
Ed25519 still seems nice, but perhaps one shouldn't hurry to switch to it -- especially if the software support isn't great, and/or there are other difficulties.
In my experience, software support is pretty wide. I do have an RSA key in case the ed25519 isn't accepted but I think it's been a year since I've had to use it.
The much nicer part about Ed25519 is that you can realistically type it out over a serial console or over a monitor-keyboard without access to copy-paste directly. They're small and fast and convenient.
In addition to that, the cryptography behind Ed25519 is much simpler to implement than RSA without causing massive side channel leaks, so that is one less thing to worry about.
In terms of Anti-QC Resistance, I wouldn't worry about it until we complete the current qc-resistant crypto competition, which should give us a nice set of primitives to use.
Most of the time it isn't my version on OpenSSH client that limits me but the remote software I'm connecting to. If I can generate an Ed25519 ssh key I will, but most of the time it isn't supported.
I'll usually go with the same order of the preference in the article, Ed25519 then ECDSA then RSA. I haven't yet seen a server not support RSA. But fairly recently I had to register an RSA 4096 on a Bitbucket Server because it did not support both elliptical curve algorithms.
So yeah, it's definitely lacking a lot of software support, but I'll use it if possible.
The quoted text is what I saw, with "Generate [...]" in place of a shell command. Found that to be amusing, since it looks like a command, while it isn't the intended one.
GCP didn't either last year. Not sure about Azure but on GCP it was very non obvious that you couldn't connect to the Compute instance because of a not supported key type.
Sure in that national level entities could in theory crack 1024 RSA. They would be stupid to tie up such a valuable resource for a year or so on breaking a single SSH connection. They would instead use it on something that got them thousands or even millions of connections.
>If it has 3072 or 4096-bit length, then you’re good. Less than that, you probably want to upgrade it.
There is zero evidence that anyone will ever break 2048 bit RSA short of some sort of huge breakthrough. I don't know where these claims are coming from...
It's about being cautious. If we want secure systems for the masses, we need to advance cryptographic defenses faster than we have proofs the attackers are advancing.
Most crypto we consider broken today "had zero evidence that anyone would ever break it" before it actually happened...
[Edited: This used to begin "However SSH keys enjoy forward secrecy" but on more consideration that's the wrong way to look at it anyway]
The only role your SSH key plays (which is why you can use Ed25519) is to make signatures. So, if the government discovers next Thursday how to break my archaic RSA key, they don't magically get to read transcripts of SSH sessions they recorded, they only get some sort of attack that could help them to impersonate me on fresh connections after Thursday.
Essentially the authentication step goes like this:
You: I know the private key corresponding to this public key 123456, does that help?
Server: (Examines authorized_keys list) That would work, prove you know that key
You: <Signature of SSH setup transcript using private key>
Server: Welcome southerntofu
All this is happening inside an encrypted session. Your client (and remote servers) automatically negotiate the safest mutually intelligible session key agreement and encryption to set that up, independent from stuff like your personal keys.
I think the same thing about SHA-1. It is possible to generate a collision with it, but it is costly, inefficient and practical.
If you design software, then yes you should put mechanisms in place to replace older and less secure ciphers with new ones, and prefer and limit the ones you chose for some who are considered safe at the moment. But I don't think we should put red flags all over a cipher or a hashing functions because someone with unlimited resources and money managed to fool it once.
The aspect here is that we have zero evidence that the next breakthrough would allow the cracking of 2048 bit RSA and not, say, 4096 bit RSA. Chances are, any such breakthrough would allow a more general solution. See quantum computing for an example where this would be true.
The inherent uncertainty of cryptography seems to cause people to want to do something, anything, in an attempt to decrease the uncertainty, even if there is no rational reason behind the approach.
it is above all a question of prudence.. There are a lot of cryptographs working on the question of size of cryptographic keys and behind all the recommendations.
If you have a doubt, use this: https://www.keylength.com/en/
And use the primitives advised by the organization you trust the most
I'm not sure if I understand the reasoning here. The article says a 1024-bit RSA key is considered unsafe, but still says you should "probably want to upgrade" if you're on a 2048-bit key. Why would that be the case? The given arguments, key size, speed etc, are complete non-arguments to me as compared to going through my keys and updating them everywhere where necessary.
Regular key rotation is a best practice that improves security.
Even if the underlying ciphers have not changed, the value of a stolen key will decay when there is a planned sunset. In the lack of a rotation strategy, a stolen key is a gift that keeps on giving.
OpenBSD introduced the signify command, and a 6-month key rotation, that will allow trust when the OS is downloaded over insecure channels (cleartext FTP and http).
Create new keys and start using them for any new setup you do. If you want to do a bit more, setup the newly created keys in the 1 or 2 most critical places.
Interesting note: Packaged versions of GPG2 did not support ED25519 keys at the time this was written.
Additionally some major openpgp packages (notably Golangs) does (or did not) support ED25519 at the time of writing either.[0]
This caused the death of a bit of software I was working on because one engineer insisted on using his ED25519 key which my software could not cope with and I was not smart enough to fix it in the upstream module.
I regret following this advice in 2018. I have way too many SaaS applications that, 3 years later, still don’t support Ed25519 keys. The errors are never helpful, and each time I’ve had to troubleshoot the issue, it’s cost me at least half a day.
I will echo the other sentiment here about the lack of support for anything other than RSA keys in various products that have SSH tooling is both maddening and absurd considering that it's just a string that's passed around.
Microsoft Azure, for instance, doesn't support them. Pure idiocy.
You mean the only one widely supported in hardware devices?
I'd way rather use a hardware-backed RSA key with proof of presence support than a dirty in-RAM software key.
(not saying there are no ed25519 hardware things, but I did say "widely", and as someone who's banged his head on PKCS#11 and other fun things I stand by my statement)
An easy modification to enable quantum safety first appeared in tinyssh, using one of the DJB NTRU Prime algorithms.
OpenSSH quietly adopted the tinyssh approach as an experimental feature. Some time later, after interaction with DJB, the OpenSSH algorithm for NTRU was changed, and tinyssh followed suit.
If you want quantum-secure Ed25519, then enable sntrup761x25519 on a supported client and server.
It's closer to 16 years, for OpenSSH [1].
> Open up your terminal and type the following command to generate a new SSH key that uses Ed25519 algorithm:
> Generate SSH key with Ed25519 key type
That's broken in an amusing way. But speaking of broken things, gnome-keyring didn't support ECC for SSH the last time I've checked (a few years ago), and was/is breaking GPG too [2]. Then there are servers with old systems not supporting Ed25519 (it was added in OpenSSH version 6.5, just in 2014 [3]). The situation with smart card support wasn't quite clear the last I've checked, either.
Besides, ECC was thought to be more resistant to quantum computing attacks, but not anymore (and seems to be an easier target at regular key sizes, actually) [4], so it lost some of the appeal.
Ed25519 still seems nice, but perhaps one shouldn't hurry to switch to it -- especially if the software support isn't great, and/or there are other difficulties.
[1] https://www.openssh.com/txt/release-4.2
[2] https://wiki.gnupg.org/GnomeKeyring
[3] https://www.openssh.com/txt/release-6.5
[4] https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Qu...