Saturday, March 22, 2014

Using the RSA Algorithm for Encryption and Signatures

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.

Managing Digital RSA keys for SSH

Now each organization must ask itself roughly about: digital key creation and expiration. Does the client create the key pair? All the private keys have a passphrase? If so, what's the minimum length? Do the keys expire? What types of keys are allowed/accepted? The private keys can be copied and then cracked so these are all things to keep in consideration. In the IT world, it is important to stay abreast of security and on ahead of new vulnerabilities.

Passphrases that have also few (or too easily guessed) alphanumeric characters (including spaces) don't last. Changing the password in one private key doesn't changes it in all other copies either. In other words, changing the passphrase in the "private" official key doesn't create a ripple effect that changes the passphrase in all other copies.

You will need to also figure out your key strength.

Right now, there is no serious reason to prefer one type over any other, assuming large enough keys (2048 bits for RSA or DSA, 256 bits for ECDSA). You may specify the key size in ssh-keygen using the -b argument.

ssh-keygen -t rsa -b 4096 ~/.ssh/id_rsa

A remaining question to ask, is: how will your organization associate any key pair with each specific user? Will they use one private key to access all of your infrastructure? Will there be a separate key for each system? How many keys are allowed to access each account? What kind of accounts are allowed to be shared? This organization specific detail is best mapped  out with a security professional.