Sep 8, 2010 11:22 AM
Sep 8th, 2010

Crypto algorithms and key sizes

Cryptography has been and continues to be the most important and ubiquitous aspect of security services (firewall, secure access, VPN, authentication). There is a vast number of cryptographic algorithms and techniques that provide the aforementioned features used in different protocols. It is important to be able to understand the challenges, attacks and concerns of cryptographic algorithms in order to be able to use them efficiently. Also it is important to follow the latest developments in the field so that can be "as secure as possible".

Cryptography is used to provide Confidentiality, Integrity, Authentication, Non repudiation for communications, storage and more. Some real world applications include protocols and technologies like VPN networks, HTTPS web transactions and management through SSH. Cryptographic algorithms are divided in

  • public key algorithms

     These algorithms use different keys for encryption and decryption. Examples are DSA, RSA.

  • private key algorithms

     That share the same key for encryption and decryption. Examples are DES, 3DES, AES.

  • elliptic curve algorithms

     That function over points that belong to elliptic curves.  An example is ECDH.

(More details on algorithms and techniques will be provided in later posts)

Over the years, some algorithms have been deprecated, "broken", attacked and proven secure or in-secure. There have been publications that decrease the security of almost any algorithm. Though, the practicality and real impact of the techniques proposed is not always high. To cut a long story short, DES is an algorithms has been proven to be insecure due to its small key size and should NOT be used. Some other widely used algorithms that have been proven secure over the years are RSA, 3DES, and AES. There have been publications at times that describe techniques that decrease their security levels, but the truth is that these algorithms have proven themselves over time, and given that we use the adequate key size they can be considered secure.

Someone might ask, why aren't we using the highest key size possible? That is not always easy to do since there are trade-offs that could relate to performance, load, power and cost. For example, we would not want to use 4096-bit RSA on our PDA device for all traffic because heavy computations would exhaust its battery power quicker. The truth is that almost all devices have cryptographic acceleration engines and processors that speed up cryptographic functions significantly, but overall we would like to use "adequate security" key sizes and not overdo it so we can scale and we don't overkill our devices.

That leads use to mention how important the key size is when we chose a crptographic algorithm. Even though RSA is a secure algorithm, using a key size of 256-bits would make the algorithms easy to break given today's computing power since factoring a 256-bit integer could be achieved in a few hours. 256-bits would be impossible to factor though 15 years ago. Thus, it is important to note NIST's recommendations in Special Publication SP 800-57 and SP 800-131, where NIST presents the key sizes of algorithms and their transitions after year 2010. The following table summarizes these recommendations.

AlgorithmNew validationsExisting validations
SHA1 (sign)until Dec2010disallow after 2010, deprecated

SHA254, 256, 384, 512

3DES-2keys, SKIPJACKuntil 2010restricted after 2010, legacy
3DES-3keys, AES128,192,256OKOK
RSA2048-bits after 20101024-bits until 2010

It is obvious that as processing speeds increase, the algorithms will need to use bigger key sizes in order to provide same security levels. For more information we would recommend the reader to use NIST's SP 800-57 and SP 800-131.

Later posts of this blog will address algorithms and cryptographic techiques' details, algorithms and Cisco products and more cryptography related subjects. Readers should feel free to post comments, suggestions, questions and subjects they would like to see in the future.

Average Rating: 0 (0 ratings)


Login or Register to take actions

This Blog

Posted September 8, 2010 at 11:22 AM
Comments:0 Avg. Rating:0

Related Content