ssh-keygen defaults to creating RSA keys, but
gpg --gen-key prefers DSA/ElGamal.
Which one - RSA or DSA - is better for GPG?
RSA and DSA - misconceptions and useful information
has a couple of older RSA references and the recent DSA reference,
In 2003, RSA vs DSA Signatures - The Winner is... -- RSA.
So basically key generation is incredibly faster for DSA, which makes sense if you understand the algorithms. Signing is also faster for DSA, but not by as large a factor. RSA’s great strength is verifying which is much faster than DSA.
Recent IETF Draft: DSA with SHA-2 for DNSSEC, Expiring Jan 7, 2010.
It has some reasons for promoting DSA over RSA today.
Using DSA with SHA-256 in DNSSEC has some advantages and disadvantages relative to using RSA with SHA-256 when using 2048-bit keys. DSA signatures are much shorter than RSA signatures; at this size, the difference is 512 bits verus 2048 bits. On typical platforms using 2048-bit keys, signing DSA is about three times faster than for RSA, but verifying RSA signatures is more than ten times faster than for DSA.
The cryptographic strength of DSA is generally considered to be equivalent to RSA when the DSA public key and the RSA public keys are the same size. Such an assessment could, of course, change in the future if new attacks that work better with one or the other algorithms are found.
There are currently no known attacks on the specific set of DSA parameters chosen for this document. Such an assessment could, of course, change in the future.
But, this is only a draft at the moment.
Everyone loves the verification speed of RSA(!).
Quoting a forum discussion:
My advice would be to use an RSA signing key (the "primary" or "master" key) and an RSA subkey for encryption. The reason for using RSA for signing is mainly because RSA lets you use larger hashes than DSA does. DSA2 also lets you use larger hashes, but RSA has been supported for many years longer than DSA2 has.
I think that if you're using it in a standard way (i.e. you don't encrypt a huge amount of data) they'll both do well.
I would personally choose RSA because I've learned the algorithm, and it's one of the most beautiful algorithms I've ever seen.
Also the use of SHA-2 algorithms is possible and allowed since current revision of DSS; but I was unable to find out which revision GPG follows.
Concerning to the current DSS specification (FIPS-186-3, p. i) any hash function specified in the SHS (FIPS-180-3, p. iv) may be used:
FIPS approved digital signature algorithms shall be used with an appropriate hash function that is specified in the SHS.
This Standard specifies five secure hash algorithms - SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 - for computing a condensed representation of electronic data (message).
To the question: Both algorithms are based on mathematical problems which are not proven to be secure (RSA uses the problem of factorizing numbers and DSA uses the discrete logarithm problem), you cannot say one is more secure than the other, because not the one problem nor the other has ever been solved.
But by using DSA with SHA-1 you may have a security problem, as already said by pgs.
The fact is it probably doesn't matter much to you :) As part of preparing to generate a key-pair and as part of maintaining existing key-pairs - regardless of what asymmetric crypto you choose you should be : 1) checking current recommended key lengths 2) chose a base/modulo to optimize for signing, or verification - depending on what will be doen more often (keys to be used in issuing TLS/SSL server certificates should be optimized for verification since every web browser will check the signature... keys used to be used in signing software should be similarly optimized) 3) make sure you age your keys - been using the same key for ssh-auth for a few years, might be time to regen even if you chose a key size that is still reasonable for the application today.
Both RSA and DSA have been substantially evaluated; if you are using a realiable code base (RSAREF, RSA commercial, Mozilla/Netscape, Microsoft, OpenSSL, ...) then you probably don't care which cryptosystem you use so long as you use it correctly and utilize current best practices