198

As someone who knows little about cryptography, I wonder about the choice I make when creating ssh-keys.

ssh-keygen -t type, where type is either of dsa,rsa and ecdsa.

Googling can give some information about differences between the types, but not anything conclusive. So my question is, are there any "easy" answers for developers/system administrators with little cryptography knowledge, when to choose which key type?

I'm hoping for an answer in the style of "Use DSA for X and Y, RSA for Z, and ECDSA for everything else", but I also realise it's quite possible such simple answers are not available.

user50849
  • 2,620
  • 2
  • 19
  • 15

4 Answers4

149

In practice, a RSA key will work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys. A DSA key used to work everywhere, as per the SSH standard (RFC 4251 and subsequent), but this changed recently: OpenSSH 7.0 and higher no longer accept DSA keys by default.

ECDSA is computationally lighter, but you'll need a really small client or server (say 50 MHz embedded ARM processor) to notice the difference.

Right now, there is no security-related reason to prefer one type over any other, assuming large enough keys (2048 bits for RSA or DSA, 256 bits for ECDSA); key size is specified with the -b parameter. However, some ssh-keygen versions may reject DSA keys of size other than 1024 bits, which is currently unbroken, but arguably not as robust as could be wished for. So, if you indulge in some slight paranoia, you might prefer RSA.

To sum up, do ssh-keygen -t rsa -b 2048 and you will be happy.

Community
  • 1
Thomas Pornin
  • 330,889
  • 61
  • 807
  • 976
  • 19
    DSA always makes me uneasy because a signature generated with a broken RNG can compromise the key. RSA keys have an easier to understand and less worrisome failure mode: generating a key with a broken RNG compromises the key, running a session with a broken RNG compromises the session at most. – Gilles 'SO- stop being evil' Oct 30 '12 at 13:26
  • @Thomas I'm curious, since this question was posted before the Snowden affair. Has anything recently come to light that would affect this answer? – user50849 Sep 05 '14 at 08:37
  • 5
    No. In fact, everything that was revealed in that affair only confirms what was already known, i.e. that when big governmental agencies spy on people, then don't do it by trying to break cryptography upfront; they rather work around it. In the SSH case, they would collect metadata (this client machine connects to that server) that is not protected by the SSH protocol, regardless of the server key algorithm or size. – Thomas Pornin Sep 05 '14 at 11:28
  • 5
    "As per the SSH standard (RFC 4251 and subsequent), a DSA key will work everywhere" - In practice, that is no longer true. OpenSSH silently disabled DSA somewhere around 7.0 or 7.1. –  Oct 03 '15 at 18:26
  • 1
    As far as I have understood, this answer is no longer true. OpenSSH 7.0 deprecated ssh-dsa keys, as far as I understand due to security concertns. See http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html – Xyz Oct 29 '15 at 08:54
  • What is the reasoning behind saying 2048 is enough? And, is there an estimate for how long it will be enough? Given Moore's Law and (even though I don't know if I say something stupid here) quantum computing? I am far off from being a security expert, and I am curious where this value (2048) comes from. – exhuma Feb 03 '16 at 07:57
  • When you say RSA will work everywhere -- this is going to come off really pedantic, but it doesn't. It doesn't work places that don't support encryption keys, and in some places where the keys are technically supported, like Github, they often fail to work. A better formulation would be "Out of the available encryption systems, RSA is most likely to be supported." Or something like that. I'm sure you can word it more succinctly. – Peter Carter Apr 15 '16 at 06:46
  • @user50849 >.. posted before the Snowden affair. Has anything recently come to light ... Actually yes Snowden did revel a lot about ssh specifically what was compromised and what was not. Some of this was specifically spelled out and some was ascertained from the author who published the interview. – John Smith Apr 22 '16 at 21:36
  • Go with 4096. More is overkill. If you use ssh a lot, you can still set up multiplexing in your ssh client, in case the waiting time bothers you. – sjas Jun 07 '16 at 07:57
  • 3
    Correction on "how gov't spies on people": Sometimes they do attack the crypto. https://weakdh.org/ mentions that one NSA attack on VPNs might use their disclosed vulnerability. So don't get complacent. :-P – I answer wrong - have fun Feb 13 '17 at 18:18
  • This is rather outdated nowadays. Actually, if we’d reasonably look at processing powers, even 16384 would not be enough for RSA. Plus, RSA had a really bad name since the whole NSA debacle with built-in backdoors e.g. in the random number handling. Thankfully, we have ed29919 now, which was specifically created because both ecdsa and rsa were not trustworthy enough anymore for anyone but the most black-eyed blind followers, and I’d recommend using that nowadays. –  Feb 25 '17 at 11:59
  • 3
    @Evi1M4chine The "NSA backdoor in RSA" was a backdoor in a random-number-generator by RSA Corporation, wasn't it? Nothing to do with the algorithm also called RSA. – Stack Exchange Broke The Law Mar 24 '17 at 01:19
  • 1
    @exhuma 2048 should be enough simply because we do not yet know how to break keys of that size. It would take tens of millions of dollars to break a 1024-bit key, and 2048 is significantly larger. The best algorithm to crack RSA, called GNFS, is not fast enough to break it. And Moore's law only applies to an increase in computing power (well, transistors), but what would be needed to break RSA 2048 would be a breakthrough in factoring algorithms. And a fully capable quantum computer would break RSA of any (realistic) size. Only newer post-quantum algorithms (e.g. R-LWE) are safe from that. – forest Apr 16 '19 at 02:02
28

As gilles says DSA is risky because if you make signatures (and using your key with a ssh client to log in is effectively making signatures) on a box with a bad RNG your key can be compromised. AIUI this made Debian basically abandon DSA for keys used on their infrastructure in light of the Debian OpenSSL random number generator fiasco.

http://meyering.net/nuke-your-DSA-keys/

ECDSA is relatively new, from some quick searching it seems it was introduced in 5.7. Afaict most of these systems are out of support and should probably be migrated but we all know that doesn't happen somtimes. For example, Debian squeeze and ubuntu lucid. ECDSA has advantages in that a key can be much smaller than a RSA or DSA key for the same level of (presumed) security. Unfortunately it shares the disadvantage of DSA of being sensitive to bad random number generators. There are also concerns that the elliptic curves traditionally used may have been backdoored.

ED25519 is an even newer option, introduced by openssh 6.5. It is a variant of the ECDSA algorithm but it solves the random number generator problem and uses a "nothing up my sleeve" curve. It will probably be the best option in the long term but right now there are still supported systems out there that don't have sufficiently new openssh.

So IMO that makes RSA (with a 2048 or 4096 bit key depending on how paranoid you are) still the most reasonable choice for general use.

Edit: update to current situation as of March 2017.

Peter Green
  • 5,499
  • 1
  • 26
  • 29
Peter Green
  • 281
  • 3
  • 2
  • 13
    ECDSA has the same weakness as DSA in this respect. And in OpenSSH it's doubly fishy because OpenSSH only implements NIST curves that are suspected to be backdoored by the NSA. More info here: http://security.stackexchange.com/a/46781/15087 – Shnatsel Dec 27 '13 at 21:35
  • One mitigation for creating signatures without a good source of randomness is RFC 6979 [Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)]. I don't know if OpenSSH uses that though. – Brian Minton Aug 20 '19 at 16:41
12

Use RSA. Not for security reasons, but for compatibility reasons.

I don't recommend using DSA keys. As of OpenSSH 7.0, SSH no longer supports DSA keys by default. As the release notes for OpenSSH 7.0 say, "Support for ssh-dss host and user keys is disabled by default at run-time". Therefore, using DSA keys (ssh-dss) is just going to cause headaches.

ECDSA keys could be better, but sadly, ECDSA keys can also cause compatibility headaches on some platforms. On Fedora, gnome-keyring-daemon doesn't automatically pick up ECDSA SSH keys, so you won't be automatically prompted for a password to unlock your SSH key when you try to use it on Fedora.

RSA keys are completely free of these compatibility headaches. They're the most widely used, and so seem to be the best supported. Therefore, I recommend you generate RSA keys, to save yourself from annoyances later down the road.

As an editorial note, OpenSSH's decision to disable DSA support is a bit puzzling: 1024-bit DSA keys have approximately the same security as 1024-bit RSA keys, so it's not clear why OpenSSH disabled support for 1024-bit DSA keys but retain support for 1024-bit RSA keys. (OpenSSH still supports RSA; it has a special check to disable RSA keys that are 768 bits or shorter, but for DSA, it just disables all DSA keys, regardless of length.) Also, OpenSSH used to support DSA keys that are longer than 1024 bits in length; it's not clear why support for them has been disabled. Oh well, so it goes.

Community
  • 1
D.W.
  • 100,791
  • 34
  • 285
  • 629
  • 1
    The decision to disable DSA support isn't puzzling. https://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys – Cliff Jan 12 '17 at 00:57
  • 2
    @Cliff the link doesn't support your assertion that it's not puzzling. – Barry Kelly Nov 18 '19 at 20:14
11

DSA and ECDSA have fixed length keys, and they are US government standards meaning that they know more about the standards than the general public. RSA is better known and you can generate longer keys with it (default is 2048 as opposed to DSA's 1024 bit fixed length), so it is (arguably) better to use.

GdD
  • 17,489
  • 2
  • 45
  • 64