ssh-keygen should default to dsa not rsa

Confirmed. I think this would be a good change.

:-Dustin

Sorry, what am I thinking ...

I misread the bug report title. I prefer RSA keys to DSA keys.

An interesting analysis lies in this thread:
 * http://www.linuxforums.org/forum/linux-security/3515-rsa-versus-dsa.html

:-Dustin

Why? Based on recent events, I would think DSA would be considered worse, not better than RSA. E.g. from http://wiki.debian.org/SSLkeys

 "any DSA key must be considered compromised if it has been used on a machine with a 'bad' OpenSSL. Simply using a 'strong' DSA key (i.e., generated with a 'good' OpenSSL) to make a connection from such a machine may have compromised it. This is due to an 'attack' on DSA that allows the secret key to be found if the nonce used in the signature is known or reused."

@Neal: That's a valid critique of debian's SSL implementation not related to DSA vs RSA.

DSA is faster for signing and RSA is faster for verification.
  http://neubia.com/archives/000191.html
  ftp://ftp.rfc-editor.org/in-notes/rfc2536.txt
  http://home.pacbell.net/tpanero/crypto/dsa.html

RSA is weaker than a DSA key of the same length, so to get the same effect, one must use a longer key. I'm not sure that the neubia link above takes that into account. So if the default stays as RSA, it might be an idea to increase the default RSA key length.

These are signature algorithms anyway and only used at the beginning anyway. After the client and server authenticate, the rest is done with ciphers like Blowfish or IDEA. So for SSH it's not a problem to use DSA at all, new connections are not made that often.

I expect that someone someday will again make a bad random number generator. Maybe some proprietary box that I am pressured to use. I don't want my keys to be vulnerable just because I use them on a machine that doesn't get RNGs right. DSA is vulnerable to that problem, and RSA is not.

I agree that using a longer default key length in RSA (and in DSA also) is a good idea at this point. E.g. jdstrand points out that in the openssl file /etc/ssl/openssl.cnf default_bits is still 1024. That should be fixed, via a different bug report.

From one of your links I also reminded that: 'It is possible to implement the DSA algorithm such that a "subliminal channel" is created that can expose key data and lead to forgable signatures so one is warned not to used unexamined code.' - another strike against it.

I disagree, sorry. Other people have already pointed out a number of reasons. You mention that RSA needs a larger key size, but note that ssh-keygen already defaults to 2048-bit RSA keys.

The main reason why DSA used to be preferred by many people was that the RSA algorithm was subject to patents. Those patents have since expired.

If you think you can make a solid cryptographic argument that DSA should be the default, then you should make that argument on openssh-unix-dev (see http://www.openssh.org/list.html) rather than here. I don't feel that your argument is solid based on what I've seen, so I would rather not be in the position of forwarding it myself.

A number of the links you posted refer to performance considerations. I rather doubt that this is or should be considered relevant for SSH keys.

Neal said: "I agree that using a longer default key length in RSA (and in DSA also) is a good idea at this point." I agree on RSA, but note that keys longer than 1024 bits are not permitted by the DSS. From past conversations with people who have better Real Cryptographer credentials than I, I understand that this is because there are other avenues of attack that do not scale with key size (at least not in the same way), so there's little point in longer keys.

@Colin:

Ok. I see enough guessing in the postings here, including mine, that expert advice is needed. Where can we find an authoritative statement from People Who Have Better Real Cryptographer Credentials as to a 'best practice' for key type and key size? The manpage at least should provide a concise summary of best practices or point the way to an authoritative document.

Surely current best practice is obviously to use ssh-keygen's defaults? They're a reasonable compromise between security and performance. The defaults have changed in the past in response to changing circumstances, and will no doubt do so again when it becomes appropriate.

Note also that there is already some commentary on key sizes in the ssh-keygen manual page:

  "For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2."