SSH Keygen – RSA, DSA, Ecdsa, EdDSA
gravitational.com
SSH Keygen – RSA, DSA, Ecdsa, EdDSA
1–10 of 45 posts
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#2It might be better to put the conclusion somewhere near the top or otherwise make it more visible - it's a convoluted topic in its details with a bunch of options with very similar names. There is a simple correct answer though, and it's worth emphasizing that.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#3It should be noted that EdDSA is generally implemented in constant time, something that can't be said for RSA. (which different implementations - including OpenSSL which OpenSSH uses - have been found to implement it in a way that allows side channel attacks time and time again)
In addition I am pretty sure that if you compile OpenSSH with support only for EdDSA it does not need to be linked to OpenSSL.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#4It might be better to put the conclusion somewhere near the top or otherwise make it more visible - it's a convoluted topic in its details with a bunch of options with very similar names. There is a simple correct answer though, and it's worth emphasizing that.
The answer is Ed25519, as most people probably expected.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#5If you setup SSH keys a while ago, you might want to run the below command to discover the type / key strength. If you're reading HackerNews comments, this might be good time to run an audit. Also; before going all in on Ed25519, native support from some cloud providers is limited.
$ for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#6The conclusion has the line:
> […] while EdDSA performs much faster and provides the same level of security with significantly smaller keys.
For non-embedded systems, how important is the speed and/or size consideration?
Keys are (IIRC) only used on initial contact, and the bulk of traffic operations will use symmetrical algorithms, so it it that big of a deal?
Perhaps throwing around a comparatively short "id_ed25519.pub" is easier?
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#7It might be better to put the conclusion somewhere near the top or otherwise make it more visible - it's a convoluted topic in its details with a bunch of options with very similar names. There is a simple correct answer though, and it's worth emphasizing that.
The answer is Ed25519, as most people probably expected.
It's not about the answer itself but the structure of the piece. For that kind of info, this is the better template:
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#8The conclusion has the line: > […] while EdDSA performs much faster and provides the same level of security with significantly smaller keys. For non-embedded systems, how important is the speed and/or size consideration? Keys are (IIRC) only used on initial contact, and the bulk of traffic operations will use symmetrical algorithms, so it it that big of a deal? Perhaps throwing around a comparatively short "id_ed2551…
It can take a surprisingly long time to do the initial exchange on a smart card.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#9The conclusion has the line: > […] while EdDSA performs much faster and provides the same level of security with significantly smaller keys. For non-embedded systems, how important is the speed and/or size consideration? Keys are (IIRC) only used on initial contact, and the bulk of traffic operations will use symmetrical algorithms, so it it that big of a deal? Perhaps throwing around a comparatively short "id_ed2551…
Symmetric keys encrypt the entire session but asymmetric keys encrypt each communication during the session.
But yeah, non embedded systems aren't as constrained. At least for practically generating SSH keys, RSA is just as fine.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#10It might be better to put the conclusion somewhere near the top or otherwise make it more visible - it's a convoluted topic in its details with a bunch of options with very similar names. There is a simple correct answer though, and it's worth emphasizing that.
The answer is Ed25519, as most people probably expected.
Or RSA 4096.
Ed25519 certainly looks the best given the fact that all the spooks (NIST, cryptlib, Crypto++ ...) lobby against it, and didn't implement it. Looks like that is the one they want nobody to use, even if it's the simplest. However, any elliptic curve in general can be backdoored, the FSF recommends RSA 4k only. Even if RSA side channel attacks are known.