
SSH Keygen – RSA, DSA, Ecdsa, EdDSA - Vmody2
https://gravitational.com/blog/comparing-ssh-keys/
======
rakoo
SSH is basically everywhere, and the key generation topic keeps coming
regularly. At this point it probably deserves an entry in the Cryptographic
Right Answers ([https://latacora.micro.blog/2018/04/03/cryptographic-
right-a...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html)) to end debates once and for all

~~~
kbirkeland
While not explicitly pointed toward SSH, the "Asymmetric signatures" section
covers this. Their recommendation is to use Ed25519 and avoid all other
options mentioned in the article.

------
tialaramex
Three of these four algorithms are only for signing and although you can use
RSA to do either, in SecSH (and thus modern SSH) it is only used for signing.

So it's a red flag when articles like this start jabbering about using these
signature algorithms for encryption:

> This is what is meant by asymmetric encryption. [Figure 2] If Bob encrypts a
> message with Alice’s public key, only Alice’s private key can decrypt the
> message. This principle is what allows the SSH protocol to authenticate
> identity. If Alice (client) can decrypt Bob’s (server) message, then it
> proves Alice is in possession of the paired private key. This is, in theory,
> how SSH keys authentication should work.

No. This isn't how SSH works, and it's confusing to me that people prefer to
imagine how it could work rather than just read the specification. RFC4252
explains exactly how public key authentication is performed. Alice _signs_ a
standard message bound to this SSH session using her private key, and Bob can
verify that this signature is correct using her public key.

~~~
i-am-curious
> This principle is what allows the SSH protocol to authenticate identity.

This part is also confusing. I feel like it is important to clarify that
identity is not "established" using cryptography, rather verified. When Bob
claims to be the Bob, you don't know and can't know just from this claim if
Bob is indeed the Bob. To verify that this Bob is indeed the Bob, you have him
certify from someone else that you trust that he is indeed the Bob (or you
just certify it yourself when your computer asks you to trust a new
fingerprint).

------
hal9000-tng
This isn't that complicated.

The answer is, simply: ED25519 if you're using modern services that support
it.

or RSA (4096 or at least 2048 bits) for services that cannot handle ED25519
(including AWS -- yes, still, even in 2020.)

So you should probably generate both to cover most possible scenarios:

    
    
        ssh -t ed25519      # for most purposes (not AWS)
        ssh -t rsa -b 4096  # for when you're not using something like Userify

~~~
lervag
It should be "ssh-keygen", not "ssh".

    
    
        ssh-keygen -t ed25519
        ssh-keygen -t rsa -b 4096

~~~
hal9000-tng
Oops :) thanks for the catch!

------
benarent
If 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

~~~
gnufx
There's support in hardware tokens to consider too.

~~~
m-p-3
I'd use my Yubikey 4 more if it did.

~~~
tialaramex
More if it did what? If you're avoiding the Yubikey's onboard ECDSA because
you're worried ECDSA is weaker than EdDSA that's definitely crazy. The main
thing the Yubikey is doing for you is protecting that private key from just
straight up getting stolen, whereupon it could be some future quantum-proof
magic and you're still screwed because now the adversary has it.

The OpenSSH FIDO implementation offers ECDSA because it makes sense to use
ECDSA on older authenticators that don't offer anything better rather than go
without. If there were any stand alone authenticators (as opposed to hybrid
software like Microsoft Hello) that only offered RSA then I suspect OpenSSH
would sigh and allow that too. For all that Safer Curves makes out it's the
end of the world, bad guys really _do_ steal SSH private key files and they
_don 't_ actually perform crazy timing attacks on ECDSA because it's very
hard.

------
dependenttypes
It 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.

~~~
throw0101a
> _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._

With the proviso (IIRC) that you will also only have AES-CTR and ChaCha.

~~~
dependenttypes
I do not know about AES but I do know that it also supports Poly1305 to be
used with Chacha20.

------
pvg
It 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.

~~~
jandrese
The answer is Ed25519, as most people probably expected.

~~~
rurban
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.

~~~
a1369209993
Fuck RSA.[0][1]

> The fact that RSA is still in widespread use today indicates both a failure
> on the part of cryptographers for not adequately articulating the [ _many_ ]
> risks inherent in RSA, and also on the part of developers for overestimating
> their ability to deploy it successfully.

0: PoC||GTFO 20
([https://www.alchemistowl.org/pocorgtfo/pocorgtfo20.pdf](https://www.alchemistowl.org/pocorgtfo/pocorgtfo20.pdf))
20:09 (p 68)

1: Why yes, that _is_ a direct quote.

------
throw0101a
The 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?

~~~
jeffbee
It can take a surprisingly long time to do the initial exchange on a smart
card.

~~~
nytgop77
smart card is kind of embedded system by it self.

------
benlivengood
The only downside to Ed25519 is that it will fall to quantum computing before
RSA 4096.

~~~
nobodyshere
Except nobody knows when that's gonna really happen. I've personally switched
to ed25519-sk wherever I could.

~~~
lucb1e
Same, the short key looks much nicer and both will fall to quantum anyhow.
Haven't run into any incompatibilities among the services I use.

