Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
5  
Only RSA is an encryption algorithm. Both DSA and ECDSA are used for digital signing - the latter being an Elliptic Curve implementation of DSA (Digital Signature Algorithm). Elliptic curve cryptography is able to provide the same security level as RSA with a smaller key and is a "lighter calculation" workload-wise. So, use RSA for encryption, DSA for signing and ECDSA for signing on mobile devices. – Henning Klevjer Oct 30 '12 at 13:01
up vote 73 down vote accepted

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.

share|improve this answer
10  
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 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 5 '14 at 8:37
1  
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 5 '14 at 11:28
3  
"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. – jww Oct 3 '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 lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/… – Aron Cederholm Oct 29 '15 at 8:54

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 rather new, from some quick searching it seems it was introduced in 5.7 and there are still some supported linux distros that carry older versions of openssh than that. For example, Debian squeeze and ubuntu lucid. Afaict it has advantages in that a key can be much smaller for the same level of security but a large RSA key is plenty secure enough and not too big to handle.

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

share|improve this answer
7  
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: security.stackexchange.com/a/46781/15087 – Shnatsel Dec 27 '13 at 21:35

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.

share|improve this answer
    
According to the ssh-keygen man page, you have three choices for ECDSA key lengths: For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. Attempting to use bit lengths other than these three values for ECDSA keys will fail. – Shrek Nov 23 '13 at 2:31
    
@jfmercer 521 or 512? – Anonymouse Aug 6 '14 at 18:01
2  
@Anonymouse it's really 521. See also crypto.stackexchange.com/questions/2482/… – nodakai Aug 21 '14 at 10:10
1  
@Anonymouse See Why do the elliptic curves recommended by NIST use 521 bits rather than 512?. In short, P521 uses this prime because 2^521-1 is a mersenne prime. – CodesInChaos Oct 21 '14 at 11:51

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.

share|improve this answer

Re: OpenSSH's decision to disable DSA support is a bit puzzling!

DSA works perfectly which presents a problem for the guys wanting to hack and own all your encrypted communications, whereas Duel_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG which is the discontinued algorithm from NIST which has been tampered with by the NSA according to the snowden leaks now comes included in your new vPro intel chips making breaking your cryptographic primes sooo much easier, for everybody including all the criminals.

RC4 was broken as a WEP implementation, when you hear the argument being presented that ARC4 is to no longer to be used by the IETF - the internet engineering task force (LOL) another name for google.inc then you should read up about RC4 and side channel attacks. http://saluc.engr.uconn.edu/refs/sidechannel/chari02template.pdf

RC4 is actually problematic when it comes to side-channel attacks, however that doesnt stop the IETF - google & cough bell-labs bringing you all poly and chacha and ECDSA which they claim is better! (taken with a pinch of salt) oh and as for backdoors in your Linux box read up about the sgi kernel debugger from Mozilla! Pwning the internet works in theory, but in practice? Not so easy when meny eye's (pun) make all thieves and spies shallow!

GOOGLE_ECDHE_RSA_WITH_CHACHA20_POLY1305 = 0xCC13, GOOGLE_DHE_RSA_WITH_CHACHA20_POLY1305 = 0xCC15, GOOGLE_ECDHE_RSA_WITH_CHACHA20_POLY1305 = 0xCC13, GOOGLE_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = 0xCC14, GOOGLE_DHE_RSA_WITH_CHACHA20_POLY1305 = 0xCC15,

Cryptographers note: EC - Stand's for Elliptic Curve (Poly1305!)

Backdoor computing - See "Ken Thompson's" Marvelous article on "Reflections of Trusting Trust!" 9P - The invisible hackers protocol you can not see, until it's deep inside your PC debugging your Kernel and these guys charged with protecting you on the internet make hacking you so damned easy!

share|improve this answer
2  
This is not even related to an answer to the question. – dave_thompson_085 Feb 26 at 7:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.