Cisco Blogs

Cryptographic Algorithm Transitions (2010-2011)

- March 24, 2011 - 1 Comment

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 information security features that are used in different protocols and functions. 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. Just as important is the ability to follow the latest developments in the field so that we can be “as secure as possible.” This post is trying to present the latest transformations in the cryptography field to raise awareness on what the status quo is on recommended algorithms and key sizes.

Cryptography is used to provide confidentiality, integrity, authentication, nonrepudiation 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, in general, are divided into the following:

  • public key algorithms: These algorithms use different keys for encryption and decryption that are mathematically related. Examples include DSA and RSA.
  • shared key algorithms: These algorithms share the same key for encryption and decryption. Examples include DES, 3DES, AES.
  • elliptic curve algorithms: These algorithms function over points that belong to elliptic curves. Examples include ECDH and MQV.

Public and shared key cryptography has been around for a long time; whereas elliptic curve cryptography (ECC) has gained attention and adoption in recent years, but has existed as a mathematical concept for a long time. (For the purpose of this post I will not focus on how the above algorithms are designed and the operations they involve, I will rather assume that the reader is familiar with basic cryptographic concepts).

Over the years, some algorithms have been deprecated, “broken”, attacked, and proven secure or insecure. There have been publications that compromise or affect the perceived security of almost any algorithm. Though, the practicality and real impact of the techniques proposed to break cryptographic algorithms is not always high. To cut a long story short, DES and MD5 are algorithms that have been proven to be insecure due to their small key (DES) and hash size (MD5). 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 an adequate key size for the technology available today (to eliminate the chance of a brute-force attack) they can be considered secure.

Someone might ask why we do not use the largest key size that is possible in our algorithms. That would provide the best possible security; however, it is not always easy to practice since there are trade-offs that could relate to performance, load, power, and cost. For example, we might not want to use 4096-bit RSA on our PDA device for all traffic exchanges because heavy computations would quickly exhaust its battery power. Nowadays 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. That being said, we also need to stress how important the key size is when we choose a cryptographic algorithm for any security function, encrypted communication, encrypted storage, or whatever it might be. For example, even though RSA is a secure algorithm, using a key size of 256-bits would make key guessing attacks easy to break given today’s computing power (factoring a 256-bit integer could be achieved in a few hours). However, 256-bits would have been impossible to factor 15 years ago and thus such a key size would have been considered secure. A “secure” key size is always in respect to its era (256-bit example 15 years ago). A “secure” algorithm is a function of its maturity in the field and if publications or methods exist that have proven it insecure.

Then what key sizes and what algorithms are secure for us today? At this point, it is important to note NISTs recommendations in Special Publications SP 800-131A, B and C (at the time this post is written), where NIST tries to present the key sizes of algorithms and their transitions after year 2010. The following table summarizes these recommendations.

Algorithm Use
MD5 not even mentioned in FIPS 140-2 for signature generation or verification
SHA1 for sig generation: good until Dec2010, deprecated until 2013, disallow after 2013,
legacy for sig verification after 2010,
OK for non-signature functions
SHA254, 256, 384, 512 OK
SKIPJACK encryption: good until 2010, disallowed after
decryption: acceptable until 2010, legacy after
3DES-2keys encryption: good until 2010, restricted until 2015, disallowed after
decryption: acceptable until 2010, legacy after
3DES-3keys, AES128,192,256 OK
RSA, DSA 1024-bits: for sig generation good until 2010, deprecated until 2013, disallowed after, for sig verification legacy after 2010
2048-bits: OK
DH 1024-bits: good until 2010, deprecated until 2013, disallowed after
2048-bits: OK
EC MQV 160-bits until 2010, deprecated until 2013, disallowed after 2013
224-bits or higher with h confactor adjusted accordingly: OK

It is obvious that as processing speeds increase, the algorithms will need to use bigger key sizes in order to provide equivalent security levels. For more information I would recommend the reader to use NIST’s SP 800-131A, B and C and generally follow NISTs recommendations as time progresses. To this point, NSA has introduced Suite B that tries to describe the NSA-approved algorithms for cryptographic interoperability and for NSA-approved information assurance that also follow NISTs standards or recommendations. Amongst others, NSAs Suite B describes the following alogrithms:

  • 128 and 256-bit AES for encryption
  • 256 and 384-bit curve ECDH for key exchange
  • 256 and 384-bit Elliptic Curve Signature Algorithm for digital signatures
  • SHA-256 and SHA-384 for hashing

Finaly, it is worth noting that the aforementioned recommendations are NISTs updates on what is considered secure today. Many factors are taken into consideration, with technology and research development at the top. It might be a longer journey for administrators, devices, and security professionals to adapt to the latest changes and that is reasonable. I would like to clarify that if people are using 1024-bit RSA for TLS, they are not vulnerable to key guessing attacks overnight after 2010. They are still almost as secure as they were the day before, but awareness to start moving to more secure keys should also be in their mind.


All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. security is not about restriction is about having a clear confidence that without taking measures that will harm your infrastructure you will have the ability to outperform without any worry of mischief or damage.