A (relatively easy to understand) primer on elliptic curve cryptography

Everything you wanted to know about the next generation of public key crypto.

Author Nick Sullivan worked for six years at Apple on many of its most important cryptography efforts before recently joining CloudFlare, where he is a systems engineer. He has a degree in mathematics from the University of Waterloo and a Masters in computer science with a concentration in cryptography from the University of Calgary. This post was originally written for the CloudFlare blog and has been lightly edited to appear on Ars.

Elliptic curve cryptography (ECC) is one of the most powerful but least understood types of cryptography in wide use today. An increasing number of websites make extensive use of ECC to secure everything from customers' HTTPS connections to how they pass data between data centers. Fundamentally, it's important for end users to understand the technology behind any security system in order to trust it. To that end, we looked around to find a good, relatively easy-to-understand primer on ECC in order to share with our users. Finding none, we decided to write one ourselves. That is what follows.

Be warned: this is a complicated subject, and it's not possible to boil it down to a pithy blog post. In other words, settle in for a bit of an epic because there's a lot to cover. If you just want the gist, here's the TL;DR version: ECC is the next generation of public key cryptography, and based on currently understood mathematics, it provides a significantly more secure foundation than first-generation public key cryptography systems like RSA. If you're worried about ensuring the highest level of security while maintaining performance, ECC makes sense to adopt. If you're interested in the details, read on.

The dawn of public key cryptography

The history of cryptography can be split into two eras: the classical era and the modern era. The turning point between the two occurred in 1977, when both the RSA algorithm and the Diffie-Hellman key exchange algorithm were introduced. These new algorithms were revolutionary because they represented the first viable cryptographic schemes where security was based on the theory of numbers; it was the first to enable secure communication between two parties without a shared secret. Cryptography went from being about securely transporting secret codebooks around the world to being able to have provably secure communication between any two parties without worrying about someone listening in on the key exchange.

Whitfield Diffie and Martin Hellman.

Modern cryptography is founded on the idea that the key that you use to encrypt your data can be made public while the key that is used to decrypt your data can be kept private. As such, these systems are known as public key cryptographic systems. The first, and still most widely used of these systems, is known as RSA—named after the initials of the three men who first publicly described the algorithm: Ron Rivest, Adi Shamir, and Leonard Adleman.

What you need for a public key cryptographic system to work is a set of algorithms that is easy to process in one direction but difficult to undo. In the case of RSA, the easy algorithm multiplies two prime numbers. If multiplication is the easy algorithm, its difficult pair algorithm is factoring the product of the multiplication into its two component primes. Algorithms that have this characteristic—easy in one direction, hard the other—are known as trapdoor functions. Finding a good trapdoor function is critical to making a secure public key cryptographic system. Simplistically, the bigger the spread between the difficulty of going one direction in a trapdoor function and going the other, the more secure a cryptographic system based on it will be.

A toy RSA algorithm

The RSA algorithm is the most popular and best understood public key cryptography system. Its security relies on the fact that factoring is slow and multiplication is fast. What follows is a quick walk-through of what a small RSA system looks like and how it works.

In general, a public key encryption system has two components, a public key and a private key. Encryption works by taking a message and applying a mathematical operation to it to get a random-looking number. Decryption takes the random looking number and applies a different operation to get back to the original number. Encryption with the public key can only be undone by decrypting with the private key.

Computers don't do well with arbitrarily large numbers. We can make sure that the numbers we are dealing with do not get too large by choosing a maximum number and only dealing with numbers less than the maximum. We can treat the numbers like the numbers on an analog clock. Any calculation that results in a number larger than the maximum gets wrapped around to a number in the valid range.

In RSA, this maximum value (call it max) is obtained by multiplying two random prime numbers. The public and private keys are two specially chosen numbers that are greater than zero and less than the maximum value (call them pub and priv). To encrypt a number, you multiply it by itself pub times, making sure to wrap around when you hit the maximum. To decrypt a message, you multiply it by itself priv times, and you get back to the original number. It sounds surprising, but it actually works. This property was a big breakthrough when it was discovered.

To create an RSA key pair, first randomly pick the two prime numbers to obtain the maximum (max). Then pick a number to be the public key pub. As long as you know the two prime numbers, you can compute a corresponding private key priv from this public key. This is how factoring relates to breaking RSA—factoring the maximum number into its component primes allows you to compute someone's private key from the public key and decrypt their private messages.

Let's make this more concrete with an example. Take the prime numbers 13 and 7. Their product gives us our maximum value of 91. Let's take our public encryption key to be the number 5. Then using the fact that we know 7 and 13 are the factors of 91 and applying an algorithm called the Extended Euclidean Algorithm, we get that the private key is the number 29.

These parameters (max: 91, pub: 5, priv: 29) define a fully functional RSA system. You can take a number and multiply it by itself 5 times to encrypt it, then take that number and multiply it by itself 29 times and you get the original number back.

Let's use these values to encrypt the message "CLOUD".

In order to represent a message mathematically, we have to turn the letters into numbers. A common representation of the Latin alphabet is UTF-8. Each character corresponds to a number.

Under this encoding, CLOUD is 67, 76, 79, 85, 68. Each of these digits is smaller than our maximum of 91, so we can encrypt them individually. Let's start with the first letter.

We have to multiply it by itself five times to get the encrypted value.

67×67 = 4489 = 30 *

*Since 4489 is larger than max, we have to wrap it around. We do that by dividing by 91 and taking the remainder.

4489 = 91×49 + 30

30×67 = 2010 = 8

8×67 = 536 = 81

81×67 = 5427 = 58

This means the encrypted version of 67 (or C) is 58.

Repeating the process for each of the letters, we get that the encrypted message CLOUD becomes:

58, 20, 53, 50, 87

To decrypt this scrambled message, we take each number and multiply it by itself 29 times:

58×58 = 3364 = 88 (Remember, we wrap around when the number is greater than max.)

88×58 = 5104 = 8

…

9×58 = 522 = 67

Voila, we're back to 67. This works with the rest of the digits, resulting in the original message.

The takeaway is that you can take a number, multiply it by itself a number of times to get a random-looking number, and then multiply that number by itself a secret number of times to get back to the original number.

118 Reader Comments

These parameters (max: 91, pub: 5, priv: 29) define a fully functional RSA system. You can take a number and multiply it by itself 5 times to encrypt it, then take that number and multiply it by itself 27 times and you get the original number back.

These parameters (max: 91, pub: 5, priv: 29) define a fully functional RSA system. You can take a number and multiply it by itself 5 times to encrypt it, then take that number and multiply it by itself 27 times and you get the original number back.

Should the "27" be "29"?

Yes, it should 29, not 27. Thanks for pointing out the error. It has been corrected.

A few minor corrections:* A function that's easy to compute but hard to invert is called a one-way function; a trapdoor function is a one-way function that's easy to invert given some auxiliary info (called the trap door).* RSA and Diffie Hellman are not really rigorously proven secure: each is secure only under an assumption that essentially states that it is secure. In fact, it's not even known whether one-way functions exist.* There is still no known polynomial-time algorithm to factor, so the claim that factoring is easier relative to multiplication as the key size increases is false. In fact, factoring gets much harder as the key size increases whereas multiplication barely gets harder at all.* A trapdoor function where the easy and hard way get harder at the same rate is terrible - the easy way must grow polynomially in the key length while the hard way must grow super-polynomially. Ideally the easy way grows linearly in the key length and the hard way grows exponentially.

I don't understand the definition of the elliptic curve "dot" function for the same point. A dot B is clear, since it is based on the one and only line passing through A and B. A dot A is confusing, because there are infinite lines that pass through A and A, since that only restricts it to one point.

The ECDSA digital signature has a drawback compared to RSA in that it requires a good source of entropy. Without proper randomness, the private key could be revealed.

Interestingly enough, this doesn't have to be the case. While traditional ECDSA does rely on a good source of randomness it's possible to modify it so that signing is entirely deterministic, yet it's still secure and the resulting signatures are still accepted by all existing ECDSA implementation. Loosely speaking, the trick is to hash the private key and the message hash being signed together with something like SHA-256 and use the result as k instead of a random value (I'm omitting some important details).

This is generally believed secure because it's unlikely two distinct signatures will have the same k, and it shouldn't be possible for an attacker to use the way k is generated to guess it unless they already know the target's private key anyway.

"Take a closer look at the elliptic curve plotted above. It has several interesting properties.

One of these is horizontal symmetry. Any point on the curve can be reflected over the x-axis and remain the same curve. A more interesting property is that any non-vertical line will intersect the curve in at most three places." (From page two).

I did take a closer look, and that all seems to make sense, excerpt why the line has to be defined as non-vertical - I can't see how a vertical line could intersect the curve in three places, so can't we just say that any line will intersect the curve in at most three places?

As I'm not a mathematician, my question is probably due to my unfamiliarity with elliptic curves, I'm only basing my comment on the curve shown in the article. Would love to understand it better though!!

This is a subtle distinction, thanks for pointing it out. RSA and Diffie Hellman are reducible to trap door number theoretic algorithms that are not proven to be one way. However, there is no currently known algorithm to efficiently solve these problems. When it comes to the ratio between how hard problem grows versus the easy problem, the ratio between factoring and multiplication grows more slowly than the ratio between elliptic curve discrete logarithm and pointwise operations.

The "dot" function for a point and itself comes from drawing a line tangent to the curve at that point. Imagine if both points were infinitesimally close to each other on that line, the line through them would be parallel to the curve at the point.

The "dot" function for a point and itself comes from drawing a line tangent to the curve at that point. Imagine if both points were infinitesimally close to each other on that line, the line through them would be parallel to the curve at the point.

As for the ECC patents, I guess we should feel lucky Blackberry is in the situation where they have to sell their patents, and Google is probably interested in their patents, too, but not sure if the ECC patents specifically. I sure hope they are, and if they get them, I hope they make them public domain, if not we can petition them to make them public domain.

The ECDSA digital signature has a drawback compared to RSA in that it requires a good source of entropy. Without proper randomness, the private key could be revealed.

Interestingly enough, this doesn't have to be the case. While traditional ECDSA does rely on a good source of randomness it's possible to modify it so that signing is entirely deterministic, yet it's still secure and the resulting signatures are still accepted by all existing ECDSA implementation. Loosely speaking, the trick is to hash the private key and the message hash being signed together with something like SHA-256 and use the result as k instead of a random value (I'm omitting some important details).

This is generally believed secure because it's unlikely two distinct signatures will have the same k, and it shouldn't be possible for an attacker to use the way k is generated to guess it unless they already know the target's private key anyway.

I believe this is what you are talking about:"Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"http://tools.ietf.org/html/rfc6979

Speaking of the need for good sources of entropy, what is the consensus opinion of cryptographers on the quality of Intel's latest random number generator (as of Ivy Bridge), accessed via RDRAND? It sounds pretty good, but what are the chances that it will eventually be found to have exploitable biases?

"It's like, in our bizarro billiards game, when a ball hits the edge of the board (the max) and then is magically transported to the opposite side of the table and continues on its path until reaching a point, kind of like the game Snake."

I've never seen a Snake-type game with wrapping edges. I think you mean a game like Asteroids...

I have to say, I am probably going to prefer RSA in my programs for the time being. And the reason is pretty simple: I can easily understand how RSA works with all its details while ECC is just so much more complicated.This leads to two advantages for RSA (imho): First of all, when implementing something you understand there is always a better chance that you don't mess up some virtal part just because you had no clue what it actually does or how important that detail was. Even though most of the time you'll use some library which provides the encryption implementations, many bugs and flaws found in applications when it comes to encryption often did look like they wouldn't have happend if the author understood what he did.

Second: Since I can understand the problem RSA is based on, I do have the feeling I can assess how secure it is. Obviously I might be wrong but at least and feels like a decision I can make. Because ECC is more of a blackbox to me, I do have to trust others when they say "That's secure". And trust is something I do not like to rely on when it comes to encryption.

The argument that we need short keys because of mobile devices does not really seem valid too me. The processing power necessary for RSA -even with huge keys - is ridiculously small compared to the available speed even on the slowest mobile device.

I have nothing of substance to contribute beyond: if you were studying crypto at the U of C in the early-to-mid 2000s, then chances are we knew each other and probably split a pitcher at the Den. In which case, congratulations on what sounds like a pretty successful career. Always nice to see a fellow grad make good.

Elliptic Curve Cryptography provides greater security and more efficient performance than the first generation public key techniques (RSA and Diffie-Hellman) now in use. As vendors look to upgrade their systems they should seriously consider the elliptic curve alternative for the computational and bandwidth advantages they offer at comparable security."

So, reading between the lines, if the NSA is strongly endorsing this kind of crypto, and marketing it as "Crypto 2.0" it's pretty clear they know it front to back and they can pretty much crack it on-the-fly.

Should a "trust no-one" strategy be considered? Cause my first and natural reaction to this is: "Trash the damn thing, do NOT follow the curve"!! :[

The "dot" function for a point and itself comes from drawing a line tangent to the curve at that point. Imagine if both points were infinitesimally close to each other on that line, the line through them would be parallel to the curve at the point.

If it's the tangent to the curve at A, wouldn't B end up (very far) to the right and below the X axis? The example almost looks like B uses the line normal to the curve at A. I understand this is just an example, but it would be nice if this was clarified.

Some nitpicks: RSA does not have a security proof, in particular it is not known whether it's equivalent to factoring -- but nobody cared about this in the early days of crypto. The success came simply because RSA and DH were making something new possible.

We usually distinguish between one-way functions and trapdoor one-way functions. The DLP-based systems use the former -- they don't ever need to retrieve the secret number; RSA belongs to the latter - computing e-th powers is hard unless you have the trapdoor information d.

The a in Google's key is a bit better known as -3.

It would be nice if you could point out that the 256-bit ECC example is also more secure than RSA-2048.

A question: Why not develop and open source algorithms to perform the required computations? If it is the quantity of computations required to break the code without the key that is difficult rather than the actual method this seems like an ideal way to prevent a backdoor. This seems obvious, am I missing something?

For normal addition of two points on the curve, you find where the straight line joining those two points hits the curve, and take the reflection across the x-axis of that third point as the sum. Maybe I missed it, but I didn't see the author mention a few special cases.

Special case A: When the straight line is tangent to the curve, it's regarded as intersecting the curve twice at that point. This convention is needed when adding a point to itself.

Special case B: If the straight line joining the two points is vertical, it is regarded as intersecting the curve at a 'point at infinity'. By convention, one additional, fictitious, point, denoted as "O", is regarded as being on the curve, namely (X=any arbitrary value, Y=+/- infinity). So, the addition proceeds by drawing the (vertical) straight line through the two points on the curve, finding where that straight line intersects the curve (at O, the fictional point at infinity), and reflecting that point across the x-axis. O is its own reflection across the x-axis, so the sum is O.

O acts as an identity element when added to an arbitrary point P on the curve. Draw the straight line between O and the other point P (i.e., the vertical line through P; All the straight lines through O are vertical.). Find where that straight line intersects the curve (namely, at P's reflection across the x-axis.). Reflect that across the x-axis, and, voila, the sum of O and P is ... P.

The "dot" function for a point and itself comes from drawing a line tangent to the curve at that point. Imagine if both points were infinitesimally close to each other on that line, the line through them would be parallel to the curve at the point.

If it's the tangent to the curve at A, wouldn't B end up (very far) to the right and below the X axis? The example almost looks like B uses the line normal to the curve at A. I understand this is just an example, but it would be nice if this was clarified.

Otherwise, fantastic article & very well written!

Yes, I don't think the animated gif is representative of the A dot A scenario. You're right that B would be far to the right and below the X axis.

Somewhat related, but not completely: it may be helpful to know that if A, B, C are points where the line intersects the curve, then A dot B dot C = 0* by the rules of the game.

*Edit: Or O in the post right above mine. I used 0 because it's the most familiar additive identity. But pretty much any symbol will do as long as its properties are understood.