During performance testing DSA is actually faster during signature generation, but slower during the validation process. Suprised? The title of this article is not misleading. With DSA it is also slightly slower when encrypting, but faster when decrypting data so security here is very close to RSA at equal key lengths.
However, since the RSA algorithm is based on the idea that large integer factorization is "difficult". Within the DSA security mechanism is an example of the discrete logarithm problem. ECDSA utilizes elliptic curve cryptography in a variant of DSA.
There is no clear winner. However, we can remember that the NIST Special Publication 800-57 (Jul 2012) recommends 2048-bit private keys. This will be important later, as it will be a factor which will elucidate the reasons for my recommendation.
If you have OpenSSL installed on your machine, you may execute :
openssl speed
You will see that the statements discussed in this article are true. Except that we did not mention that verification is what you want to be the fastest. The signature only happens once, but the verification happens an indefinite number of times. RSA also supports out of the box encryption, whereas DSA is dependent on third party encryption and is slower here as well. However, DSA is faster at decrypting so we are still only tipping the scale a tiny bit.
However, for commercial entities considering organizational security policies which will last into the future should consider RSA or ECDSA. Overall RSA is clearly the winner for the moment, even though ECDSA is actually computationally lighter than all three it is not traditionally supported (RFC 4251) for SSH. Also, being a young encryption algorithm; it has had some serious critical vulnerabilities in the recent past. Most professionals are steering away from using this type of key for the time being.
In commercial terms, RSA is clearly the winner, commercial RSA certificates are much more widely deployed than DSA certificates.
Now we reach the final decision. A DSA key has to contain a 1024-bit keystrength in order to comply with NIST FIPS 186-2. Unfortunately, while longer DSA keys are possible (FIPS 186-3) ssh-keygen restricts you to 1024 bits. When you take this article into consideration, we are no longer able to reasonably secure data with 1024-bit keys for either RSA or DSA.
However, since the RSA algorithm is based on the idea that large integer factorization is "difficult". Within the DSA security mechanism is an example of the discrete logarithm problem. ECDSA utilizes elliptic curve cryptography in a variant of DSA.
There is no clear winner. However, we can remember that the NIST Special Publication 800-57 (Jul 2012) recommends 2048-bit private keys. This will be important later, as it will be a factor which will elucidate the reasons for my recommendation.
If you have OpenSSL installed on your machine, you may execute :
openssl speed
You will see that the statements discussed in this article are true. Except that we did not mention that verification is what you want to be the fastest. The signature only happens once, but the verification happens an indefinite number of times. RSA also supports out of the box encryption, whereas DSA is dependent on third party encryption and is slower here as well. However, DSA is faster at decrypting so we are still only tipping the scale a tiny bit.
However, for commercial entities considering organizational security policies which will last into the future should consider RSA or ECDSA. Overall RSA is clearly the winner for the moment, even though ECDSA is actually computationally lighter than all three it is not traditionally supported (RFC 4251) for SSH. Also, being a young encryption algorithm; it has had some serious critical vulnerabilities in the recent past. Most professionals are steering away from using this type of key for the time being.
In commercial terms, RSA is clearly the winner, commercial RSA certificates are much more widely deployed than DSA certificates.
Now we reach the final decision. A DSA key has to contain a 1024-bit keystrength in order to comply with NIST FIPS 186-2. Unfortunately, while longer DSA keys are possible (FIPS 186-3) ssh-keygen restricts you to 1024 bits. When you take this article into consideration, we are no longer able to reasonably secure data with 1024-bit keys for either RSA or DSA.
