ar_doc_17 openssl_ECC_enc_dec_signature - JohnHau/mis GitHub Wiki
You should be using ECC for your SSL/TLS certificates RSA’s days are numbered, ECC is lighter, faster and far less vulnerable We talk about ECC all the time, but let’s be honest. It can all seem a little bit abstract, which is probably not helping its adoption-rate. The majority of the SSL/TLS certificates being issued today use RSA public key encryption. We know because we sell a lot of them.
And as far as I can tell, a large part of that can be attributed to the fact that people still think that Elliptic Curve-based cryptosystems still aren’t widely supported by end users’ browsers and operating systems.
Well, that’s not true.
So today we’re going to talk a bit about the misnomer that ECC isn’t supported, then we’ll talk a bit about ECC itself, its strengths, and why you should be using it with your SSL/TLS certificates.
Let’s hash it out.
The SSL/TLS industry has always been hamstrung by conventional wisdom that no longer holds true. Everything from the idea that HTTPS is slower to the myth that websites that don’t collect personal information don’t need SSL. While there was a time that all of these things were true (to some extent), that’s not the case today.
Add the idea that ECC isn’t widely supported by end users to that list.
While server support may vary. Here’s a breakdown of support from popular operating systems:
| Operating System | Minimum Version Required |
|---|---|
| Apple OS X | OS X 10.6 |
| Microsoft Windows | Windows Vista |
| Red Hat Enterprise Linux | 6.5 |
| iOS | iOS 7.x |
| Android OS | 3.x |
| Microsoft Windows Phone | 7.x |
Sure, Windows XP users and some very old legacy devices might have a difficult time with ECC, but that actually serves as a perfect segue to our next point.
RSA is on its last legs, just in the past two few months we’ve detailed a couple of exploits that can be used against RSA and many outdated SSL/TLS implementations. The common theme was that by continuing to support older, more vulnerable cryptosystems and ciphers, organizations were inviting undue risks in the name of interoperability.
And believe me, I understand why interoperability is desirable. Businesses are loathe to lock anyone out of their websites. But by continuing to abide that logic you’re only robbing yourself of several of the biggest benefits offered by ECC.
- ECC keys are smaller, meaning better performance with less overhead
- ECC scales better, RSA gets cumbersome as keys grow bigger
- ECC is less vulnerable to Quantum Computing, which is kind of a big deal
So, let’s give a real cursory explanation of how ECC works and then we’ll get into the benefits that should have you opting for ECC over RSA almost anytime you get an SSL/TLS certificate issued.
All modern Operating Systems and Browsers support ECC The SSL/TLS industry has always been hamstrung by conventional wisdom that no longer holds true. Everything from the idea that HTTPS is slower to the myth that websites that don’t collect personal information don’t need SSL. While there was a time that all of these things were true (to some extent), that’s not the case today.
Add the idea that ECC isn’t widely supported by end users to that list.
While server support may vary. Here’s a breakdown of support from popular operating systems:
Operating System Minimum Version Required Apple OS X OS X 10.6 Microsoft Windows Windows Vista Red Hat Enterprise Linux 6.5 iOS iOS 7.x Android OS 3.x Microsoft Windows Phone 7.x And here’s the breakdown for the four most popular browsers:
Browser Minimum Version Required Apple Safari 4 Google Chrome 1.0 Microsoft Internet Explorer 7 Mozilla Firefox 2.0 Sure, Windows XP users and some very old legacy devices might have a difficult time with ECC, but that actually serves as a perfect segue to our next point.
Look forward, not backwards – don’t prioritize interoperability over security RSA is on its last legs, just in the past two few months we’ve detailed a couple of exploits that can be used against RSA and many outdated SSL/TLS implementations. The common theme was that by continuing to support older, more vulnerable cryptosystems and ciphers, organizations were inviting undue risks in the name of interoperability.
And believe me, I understand why interoperability is desirable. Businesses are loathe to lock anyone out of their websites. But by continuing to abide that logic you’re only robbing yourself of several of the biggest benefits offered by ECC.
ECC keys are smaller, meaning better performance with less overhead ECC scales better, RSA gets cumbersome as keys grow bigger ECC is less vulnerable to Quantum Computing, which is kind of a big deal So, let’s give a real cursory explanation of how ECC works and then we’ll get into the benefits that should have you opting for ECC over RSA almost anytime you get an SSL/TLS certificate issued.
Elliptic Curve Cryptography 101 A long time ago, Vincent Lynch – who has now moved on to DigiCert – wrote an excellent summary of ECC that was designed to teach you everything you need to know in just five minutes. If you can spare the time, I highly recommend it. But here’s the abridged version:
Elliptic Curve Cryptography, as the name so aptly connotes, is an approach to encryption that makes use of the mathematics behind elliptic curves. I mentioned earlier that this can all feel a little bit abstract—this is the portion I was referring to.
Let’s start with what an X-axis is. And before you laugh, this is actually pretty critical to understanding ECC. Every point of the elliptical curve that’s being mapped is reflected across the X-axis – the horizontal line on the graph – which is what gives an elliptic curve its symmetry.
Ok, now let’s talk about dotting. Let’s take that beautiful elliptic curve from above and let’s draw on it a little bit to illustrate what I’m talking about. Two values are chosen, known only by the owner of the private key. Those points, A and B, are plotted on the elliptic curve.
Now let’s draw a line through point A & B. That line is going to intercept the elliptic curve in a third location. That’s the point we care about. It’s reflected across the X axis and becomes the next subsequent point in the sequence. So here, you can see we plot points A & B, find where it intersects for the third time and plot the inverse on the other side of the X-axis as C.
Now do it again, only this time draw a line between point A and point C, find the third point of interception on the elliptic curve and plot its inverse on the other side of the X-axis.
This is called dotting. And the number of intersection points, or dots, is known only to the private key holder making it impossible for anyone else to decrypt it without that knowledge.
Obviously, this is a Public Key cryptosystem, used for key symmetric key exchange, similar to RSA. But rather than using prime factorization for key generation it uses to elliptic curves. Both accomplish the same thing, but ECC has some decided advantages.
ECC Keys are Smaller RSA keys are unwieldy. The industry standards is 2,048 bits though some organizations go with bigger keys. That has one major disadvantages, owing to the size of the keys and the computational resources required for RSA encryption that can cause your website’s performance to lag. We’ll get into that a little bit more when we discuss RSA’s scaling issues, but the bigger problem for RSA is that the key size isn’t commensurate to its security. As the keys grow larger the strength of the security doesn’t improve at the same pace.
And despite being considerably smaller, ECC keys are much harder to crack. For instance, per a Universal Security study, the amount of energy exerted for a computer to crack a 228-bit RSA key would be about enough to boil a teaspoon of water. An ECC key of the same size, 228-bit, would require more energy than it would take to boil all of the water on Earth.
That’s substantial.
Here’s a rundown of ECC key sizes and what their RSA equivalent would be:
| ECC Key Size | RSA Key Size |
|---|---|
| 160-bit | 1024-bit |
| 224-bit | 2048-bit |
| 256-bit | 3072-bit |
| 384-bit | 7680-bit |
| 521-bit | 15360-bit |
For a little bit of context, the US National Security Agency (NSA) requires all Top Secret files and documents to be encrypted with 384-bit ECC keys. That would be a 7,680-bit RSA key, which would be absolutely unwieldy.
That leads us perfectly into our next point.
As we just mentioned, RSA is more expensive than ECC in terms of the resources required. Factorization requires quite a bit of computation. And as the threats to modern encryption grow, it’s only going to get more expensive as those RSA keys continue to get bigger and bigger.
That will ultimately be what buries RSA.
But in the meantime, there’s a more imminent problem. Especially for larger corporations and enterprises. When you get big enough, the cost of all those SSL/TLS handshakes and all of that decryption can become a major burden on your network. This is why a lot of Enterprises practice SSL offloading as part of their overall SSL/TLS implementation. By offloading those processes to dedicated devices, it frees up resources on their application servers and improves the overall performance of their websites.
Now let’s apply what we know about ECC vs. RSA: that RSA keys scale poorly compared to their ECC counterparts. As threats grow and keys need to be bigger, that’s more and more of a strain on your network. ECC, on the other hand, scales well and requires less resources in the first place.
For smaller companies this might be less of a concern, but as you grow it does become more of a consideration. One that ECC helps to mitigate.
Before we get started and someone comes screaming in the comments section, ECC in its most common iteration is not quantum-resistant. It can be beaten with a modified variant of Shor’s algorithm. But there is a form of Elliptic Curve-based cryptography that has shown promise: supersingular elliptic curve isogeny cryptography.
We’re not going to get into supersingular elliptic curve and isogeny graphs because quantum computing isn’t viable yet and I am not a math major. But SIDH, as it’s been dubbed, has two big advantages over its competitors: smaller key sizes and perfect forward secrecy.
A quick word about perfect forward secrecy. This is a practice that’s popular with privacy advocates where even if a private key is cracked the session keys it generated won’t be compromised. It’s technically possible with RSA, but it requires short-lived keys, which means regular key rotation and, as we covered, generating new RSA keys is expensive. ECC lends itself to this model given the smaller key sizes and the ease with which they can be rotated.
This could have been its own section, but we’re going to cover PFS a little more in-depth later this Spring so we’ll get into it more then.
Here’s a rundown of ECC key sizes and what their RSA equivalent would be:
ECC Key Size RSA Key Size 160-bit 1024-bit 224-bit 2048-bit 256-bit 3072-bit 384-bit 7680-bit 521-bit 15360-bit For a little bit of context, the US National Security Agency (NSA) requires all Top Secret files and documents to be encrypted with 384-bit ECC keys. That would be a 7,680-bit RSA key, which would be absolutely unwieldy.
That leads us perfectly into our next point.
ECC scales better than RSA As we just mentioned, RSA is more expensive than ECC in terms of the resources required. Factorization requires quite a bit of computation. And as the threats to modern encryption grow, it’s only going to get more expensive as those RSA keys continue to get bigger and bigger.
That will ultimately be what buries RSA.
But in the meantime, there’s a more imminent problem. Especially for larger corporations and enterprises. When you get big enough, the cost of all those SSL/TLS handshakes and all of that decryption can become a major burden on your network. This is why a lot of Enterprises practice SSL offloading as part of their overall SSL/TLS implementation. By offloading those processes to dedicated devices, it frees up resources on their application servers and improves the overall performance of their websites.
Now let’s apply what we know about ECC vs. RSA: that RSA keys scale poorly compared to their ECC counterparts. As threats grow and keys need to be bigger, that’s more and more of a strain on your network. ECC, on the other hand, scales well and requires less resources in the first place.
For smaller companies this might be less of a concern, but as you grow it does become more of a consideration. One that ECC helps to mitigate.
ECC is more quantum-resistant Before we get started and someone comes screaming in the comments section, ECC in its most common iteration is not quantum-resistant. It can be beaten with a modified variant of Shor’s algorithm. But there is a form of Elliptic Curve-based cryptography that has shown promise: supersingular elliptic curve isogeny cryptography.
We’re not going to get into supersingular elliptic curve and isogeny graphs because quantum computing isn’t viable yet and I am not a math major. But SIDH, as it’s been dubbed, has two big advantages over its competitors: smaller key sizes and perfect forward secrecy.
A quick word about perfect forward secrecy. This is a practice that’s popular with privacy advocates where even if a private key is cracked the session keys it generated won’t be compromised. It’s technically possible with RSA, but it requires short-lived keys, which means regular key rotation and, as we covered, generating new RSA keys is expensive. ECC lends itself to this model given the smaller key sizes and the ease with which they can be rotated.
This could have been its own section, but we’re going to cover PFS a little more in-depth later this Spring so we’ll get into it more then.
How can I get an ECC SSL certificate?
Getting an ECC SSL certificate is as straightforward as ordering an SSL certificate. Most SSL services and CAs will provide you with an option to pick ECC for any certificate that supports it. Not all do, though Sectigo and some Symantec/DigiCert certificates already support it.
You can also choose ECC as your signature algorithm. And here’s the biggest thing: ECC doesn’t cost any more than RSA.
But it’s a better cryptosystem for all the reasons we just covered. Key size, scalability, long-term viability.
You don’t even have to wait to get a new SSL certificate to make the switch. Most SSL services, The SSL Store™ included, offer free re-issuance of your SSL/TLS certificate. With select certificates you can simply go into your dashboard, choose to re-issue and use an ECC Certificate Signing Request (CSR) to generate your order (provided your certificate supports it).
Either way, ECC certificates are not hard to obtain.
So, why aren’t you using them?
As always, leave any comments or questions below…