The situation in the information security field is constantly changing. Hacking attempts are becoming more and more impudent and complex. Intruders develop elaborate and multistage break-in methods. The constant back and forth between hackers and security researchers, coupled with advancements in cheap computational power, results in the need for continued evaluation of acceptable encryption algorithms and standards. That is why Certificate Authorities are always working on developing new solutions and improving existing ones, which allows keeping on-line information security at the highest level. Public key cryptography and Digital certificates serve to provide a new level of authentication, privacy, and personal data transmitting security that cannot be maintained by passphrases and passwords alone.
So far, major key algorithms, RSA and DSA, have experienced wide applications in the Internet security field. RSA is currently the industry standard for public-key cryptography and is used in the majority of SSL/TLS certificates. And after more than 30 years of success, modern ECDSA (Elliptic Curve Digital Signature Algorithm) keys come on the stage.
What is an ECC (Elliptic Curve Cryptography) certificate?
ECC Certificates, as the name suggests, rely on the use of Elliptical Curve Cryptography. ECDSA (Elliptic Curve Digital Signature Algorithm) which is based on DSA, a part of Elliptic Curve Cryptography, which is just a mathematical equation on its own. ECDSA is the algorithm, that makes Elliptic Curve Cryptography useful for security.
Neal Koblitz and Victor S. Miller independently suggested the use of elliptic curves in cryptography in 1985, and a wide performance was gained in 2004 and 2005. It differs from DSA due to the fact that it is applicable not over the whole numbers of a finite field but to certain points of the elliptic curve to define the Public/Private Keys pair. While RSA is based on the difficulty of factoring large integers, ECC relies on discovering the discrete logarithm of a random elliptic curve.
Some Pros and Cons
While the required level of security can be achieved using RSA keys of sufficiently large size, it is important to note that the larger key size means it will consume more power and will significantly impact system performance in large installations. And in the era of IoT, and mobile and compact devices, ‘pure web performance’ stands up at the head of the whole business. From this perspective, the physical size of the key is a predominant question.
DSA and RSA key algorithms require a larger key size and could be defeated by factoring a large number. When it comes to ECDSA, the Elliptic Curve Discrete Logarithm Problem (ECDLP) needs to be solved in order to break the key, and there was no major progress so far to achieve this. Thus ECC certificate provides a better security solution and is more difficult to break using usual hacker’s ‘brute force’ methods.
For comparison, the strength of an Asymmetric key is converted to the equivalent of security strength of a Symmetric key.
|Security strength (bit)||RSA Public Key length (bit)||ECDSA Public Key length (bit)|
As you can see the strength of 384 bit ECDSA key is equivalent to the strength of 7680 bit RSA key. An interesting fact to note here is while most of the CA do not issue 7680 bit RSA certificates, 384 bit ECDSA certificates can be easily obtained, and even for free from LetsEncrypt using acme.sh.
The shorter the key, the faster it turns around. In order to comply with the increasing cryptographic strength requirements - sizes of keys and signatures grow as well, and so does the time spent on performing a cryptographic operation. It is obvious from the table above that the increase rate is way faster for RSA than for ECC. From the data we can easily identify some of the benefits of using ECDSA certificates:
Lower CPU use
Physical space taken by the SSL certificate
Improved server-to-browser performance
While ECC has some benefits, there are also major drawbacks that you should consider before moving to ECC. Most importantly, not all browsers and servers support ECC certificates and support in mobile platforms has not been thoroughly tested. Another concern is that while ECC is faster overall, the ECC signature verification can be a computationally intensive task and may be slower than RSA on some devices.
According to SSL Labs below are the minimum requirements to view the ECC SSL correctly:
Web Client Support
|Web Client||Minimum Version Required|
|Google Chrome||1.0 on ECC compatible OS|
|Microsoft IE||7 on ECC compatible OS|
|Apple Safari||4 on ECC compatible OS|
|OS||Minimum Version Required|
|Microsoft Windows||Windows Vista, and Windows 7&8 that reply on OS Root Store and Root Update Mechanism|
|Apple OS||OS X 10.6|
|Red Hat Enterprise Linux||6.5|
|Server||Minimum version required|
|Apache HTTP Server||2.2.26|
|IBM HTTP Server||8.0 w/ PM80235|
|Sun Java System Web Server||7.0|
It is worth mentioning that while AWS CloudFront supports ECDSA keys upto 384 bits, the maximum size of RSA key it supports is 2048 bits.
A Possible Workaround?
According to NIST, the 2048-bit RSA keys are good until 2030 keeping in mind the rate at which the computational power of computers grow. So if you are good with a slightly higher CPU usage, RSA is good for you. But if you are in a business with devices that are resource intensive, like battery-powered IoT devices, you can configure two SSL certificates in your server configuration. I personally do this and the clients that support the ECC algorithm get served an ECDSA certificate.
For Nginx, the configuration will look something like this:
ssl on; ssl_certificate /path/example.com_ecc/fullchain.cer; ssl_certificate_key /path/example.com_ecc/example.com.key; ssl_certificate /path/example.com/fullchain.cer; ssl_certificate_key /path/example.com/example.key; ssl_dhparam /path/dhparams.pem;
ECC is indeed an improvement in modern cryptography which underlies SSL certificates. Increased performance, attack stability, and viable alternative to the existing crypto algorithms are among the obvious benefits. However, considering the number of legacy systems in use it is important to weigh the possible impact of this on business. Keeping in mind that the 2048 bits RSA keys are possibly good until 2030 you can safely use them for quite some time, I would still recommend changing from RSA to ECDSA in coming years when most of the legacy systems will be out of the ecosystem. Just like RSA, ECDSA too has a bright future ahead.