Asymmetric and Symmetric Cryptography
Before we can talk about how quantum computers threaten Bitcoin and other cryptocurrencies, we first need to understand what’s actually being threatened at a fundamental level. This first post is the “cryptography 101” you need before reading the rest of this blog.
#The problem Bitcoin needs cryptography to solve
Let’s say you want to send someone some bitcoin. You need to prove that you’re allowed to spend this bitcoin over the internet, to a large group of strangers, without a bank in the middle ensuring integrity and vouching for you. On top of this, you need to do this without exposing the secret that authorizes you to spend it, in a way that would let anyone who saw it spend your money too. Whatever message you send to authorize yourself as the rightful person to spend your money needs to survive an adversary that sees literally anything and everything you ever send.
#Symmetric cryptography
The obvious and maybe naive first idea is to use a shared secret. You and the network agree on some password ahead of time, and when you want to spend your money, you show the password to the network, and in return they let you spend your money. However, there is a huge problem with this method: you can’t trust everyone else. Once you reveal your password to everyone in the network, anyone can use it to spend your money by pretending to be you. Now you are broke.
So, the shared password idea doesn’t work. But, the underlying instinct is correct. The key mistake here was that you shared your secret with everyone else. What if instead of revealing this secret to everyone to authorize yourself, you use your secret to jumble up a message into garbage that can only be de-garbagified by those you trust to share your secret with. This way, anyone eavesdropping only receives the garbage, and can’t pretend to be you and steal your money.
This is the core idea with encryption: using a secret key to scramble up a message that can only be unscrambled back into the original message using the key again.
In the context of cryptography, we refer to these ‘secrets’ as keys. The key itself can be anything that we want, like a hexadecimal string, a random integer, an image, a byte array, etc.
There’s actually a name for this kind of encryption: it’s called symmetric cryptography. To make this more precise, because “scrambling” is doing a lot of hand-waving right now, I’m going to follow Katz and Lindell’s definition [1].
Symmetric Encryption: A symmetric encryption scheme over a message space is a 3-tuple of probabilistic polynomial-time algorithms comprising
- A key-generation algorithm that outputs a key given a security parameter according to some probability distribution over the key space .
- An encryption algorithm that computes a ciphertext given a key and a plaintext message .
- A decryption algorithm that computes the message given the key and ciphertext.
The security parameter is technically an input to and really just guarantees that the key is at least bits long. It’s not that important for this post but I decided to keep it in for rigour’s sake.
It is required that for every output by , and for every ,
So does this actually fix the problem we started with? With the first password idea, the secret itself was transmitted to everyone else in the network, for any eavesdropper to see and use. With symmetric encryption, only is ever revealed to everyone else, and only needs to be revealed to the sender and recipient. An eavesdropper only sees , which reads as garbage. However, notice that both the sender and recipient need to know what is for this to work. Is that feasible in a network where you don’t trust anyone? Odds are that you will be sending many of these kinds of authorization messages to many different people in the network. You could use a different for each, but how does get sent to the recipient? If this were your friend standing in the room with you, you could simply write down and hand it to them. However, you and basically everyone in the Bitcoin network have never met, and never will. Every single bit you could possibly send over the network to reveal can and will be intercepted by an adversary. We are back at stage one. This is its own area of research, called key distribution, but it’s not what this post or this blog is about. Is there a way for two people who do not trust each other and have never met to agree on a shared secret without revealing the secret itself?
#Asymmetric cryptography
It turns out, it is possible for two people who do not trust each other to agree on this shared secret without revealing the secret itself. However, it requires a trick that seems painfully obvious once you actually see it. We need to utilize a trapdoor function: a function that’s easy to compute in one direction given some input, but extremely hard to reverse. As a physical analogy, think of squeezing toothpaste out of the tube. Squeezing it out is trivial, but getting it back into the tube is exceptionally difficult.
In the cryptographic sense, instead of generating one key that both the sender and recipient both somehow need to already have, you generate two separate keys that are mathematically linked. One of them, the public key, you are free to share with anyone, and the other, the private key, you keep to yourself. The clever part here is that anyone with knowledge of your public key can use it to encrypt your message in a way that the only way to decrypt it is with your private key. This is called asymmetric cryptography (or public key cryptography).
Following Katz and Lindell again [1], I am going to make this more precise.
Asymmetric Encryption: An asymmetric encryption scheme is a 3-tuple of probabilistic polynomial-time algorithms comprising
- A key-generation algorithm that outputs a pair of keys given a security parameter , with being the public key and being the secret key.
- An encryption algorithm that computes a ciphertext given the public key and a plaintext message .
- A decryption algorithm that computes the message given the private key and the ciphertext.
It is required that for every output by and for every message ,
The shape is basically identical to the symmetric case, with the only difference being that now outputs two keys instead of one, and and use separate keys. needs to make use of a trapdoor function because has to be computable from , but going the other way around, i.e., computing from , needs to be computationally hard. Next we will explore exactly what kind of mathematical operations allow us to do this, and why exactly we can trust that these encryption schemes are secure in the first place.
#What makes these keys hard to break?
I’m not going to walk you through how any specific encryption scheme works step by step. What I want to get across is that whichever asymmetric encryption scheme you look at, its security ultimately comes down to the “hardness” of a few specific, named computational problems. Before we can even say what these computational problems are, I am first going to be more precise about what “hard” means in this context instead of waving it around without meaning. First, I need to quickly discuss a mathematical object called a group [1].
Group: A group is a set along with a binary operation satisfying
- Closure: For all .
- Identity: There exists an identity such that for all , .
- Inverse: For all , there exists such that .
- Associativity: For all .
I promise this isn’t about to turn into a full abstract algebra lesson. We just need one more definition before I can get into what these hard problems are.
Cyclic Group: A group is cyclic if there exists an element , called a generator, such that every element can be written as for some integer .
The important part to point out is that computing given both and is fast, even for very large values of . There’s a method called repeated squaring that allows us to compute in at most computational steps. Going backwards however, is very difficult, and you can actually see why with a tiny example. Consider and . Let’s look at the group generates (mod 11).
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 5 |
| 5 | 10 |
| 6 | 9 |
| 7 | 7 |
| 8 | 3 |
| 9 | 6 |
For prime , the set of non-zero integers under multiplication modulo always forms a cyclic group of order (size) , meaning there exists such that produces every element in the set [1].
If we look at the right column, it looks essentially random. The numbers don’t follow an obvious pattern or cycle in some obvious order. If I handed you the number 3 and asked you “which power of 2 gives you this, mod 11”, your best move is to just check every number yourself. There is no structure to exploit or any shortcut to get you to the answer faster. Now imagine instead of having 10 entries in this table, we had more entries than there are atoms in the observable universe. You could combine all of the Earth’s computational power together and you still wouldn’t find the answer in your lifetime (or anyone else’s lifetime for that matter). This is one of the key computational problems that underlies asymmetric cryptography.
Discrete Logarithm Problem (DLP): Given a cyclic group of order with generator , and given , find the integer such that
The discrete-logarithm assumption is just the claim that no efficient algorithm can solve this, for the right choice of group (some cyclic groups are trivial). This is the exact assumption Diffie-Hellman key exchange is built on. It’s also one of two (three if you want to be really technical) computational problems that underpin the cryptography used in Bitcoin and other cryptocurrencies today. Luckily, the other computational problem is much easier to understand and is simpler to state.
Integer Factorization Problem: Given a semiprime , find primes such that
Much simpler, but the same idea holds. Multiplying two large prime numbers together is fast, and a computer can do this instantly, no matter how large they are. But, hand someone and tell them to factor it into and , there’s no shortcut for them to exploit and they are stuck testing candidates again. This is why and need to be prime in the first place, because if had many factors we could easily shrink the problem down as we found more factors. Nobody has ever found an efficient algorithm to solve this problem either, which is why we still rely on it for encryption today. This is the assumption RSA is built on.
I’ll go through how RSA works with a small example, since it comes up again when we get to signatures. Pick two primes, and , so . Then pick two exponents and that satisfy
which here means their product needs to leave a remainder of 1 when divided by 20.
just means and leave the same remainder when divided by . For example, , since .
Taking and works, since . Your public key is , and your private key is . Encrypting a message means computing
and decrypting means raising to the power instead,
Say . Encrypting gives
and since , decrypting gives
which is the 4 we started with. Why this works comes from a result called Euler’s theorem, which I’m not going to prove here [1]. Euler’s theorem only covers that share no factors with , like 4. The others, like 3 or 11, still come back, just for a different reason. Any from 0 to 32 works.
This is where factoring comes in. To find , we needed that 20, and the only way we got it was from and . Someone who only has has to factor 33 first. That’s easy for 33, but as we just saw, nobody knows how to do it fast for a big . In fact, finding from turns out to be just as hard as factoring [1].
Every trapdoor function that you will run into in practice more than likely relies on one of these two problems for its cryptographic hardness. However, there’s one thing to note here: ‘hard’ just means that the best known attacks take an infeasible amount of time to work (like on the order of the time until the end of the universe), and exactly how infeasible these attacks are scales with the order of the group or number of bits required to represent the primes. For groups like the example above, the best-known attacks can actually solve these problems in sub-exponential times [1], meaning that they are still slower than an efficient (polynomial time) algorithm, but faster than brute force. As a consequence, the order of the group or the size of the primes used for the keys must be large enough to outpace these algorithms. Therefore, we end up with keys of around 2048 bits. For something like Bitcoin, which needs to store and generate a large number of these keys, this size adds up fast and turns into a real bottleneck.
The obvious question to raise from here is: is there some other group we can plug into the DLP that survives these sub-exponential attacks, meaning that we don’t need to store such large keys to be safe? Turns out yes, but it’s built out of a very different kind of math that we need to introduce first.
#Elliptic curves
There is a special class of groups that allow us to sidestep this large key issue, while remaining just as secure. These groups rely on elliptic curves [1].
Elliptic Curve: An elliptic curve is the set of points satisfying
for fixed constants and prime , with and satisfying
The constraint on and ensures that the curve has no repeated roots and doesn’t cross itself at some point.
The group corresponding to the elliptic curve that we care about is the set of points satisfying the above equation, together with one special point, the point at infinity, , which doesn’t correspond to any pair, but is added purely so that the group satisfies the identity and inverse requirements. Put more formally,
for . Recall that groups require a binary operation along with the set (Group). The binary operation here is called point addition, and it’s precisely why we care about using elliptic curves for encryption in the first place. To add two points, and , we do the following operations:
- Draw a straight line connecting and .
- Find the point where this straight line intersects the elliptic curve.
- is obtained by reflecting this intersection point along the axis.
Here’s what that looks like on an actual curve.
If we wish to add with itself, denoted , we first draw the line at that is tangent to the curve, then we find the intersection of this tangent line with the curve and then reflect along the x-axis.
This is a nice visual example of how adding points on an elliptic curve works, but your computer isn’t literally going to draw out a curve and connect points like this. In fact, the points in the elliptic curve group do not form a continuous curve at all, and instead look like a handful of scattered points with no continuous shape. It needs to be done with nothing but arithmetic. To show how that looks, let’s do an example small enough to check by hand. Take the curve
with the points
Note that I have silently skipped a step here to show how exactly we get these points from the elliptic curve equation. For each from 0 to 6, compute , then ask if has a square root mod 7. If , you get one point, . If it has a square root , you get two points, and . If it has no square root, that isn’t on the curve at all. Take : , and 4 has square roots 2 and 5 mod 7, giving and , exactly what’s in the set above. Same check across all 7 values of gives you the whole curve.
Let’s add two of these points together anyway, and , using the exact same rules as before, except algebraically.
The line through both points has slope
or
In general, the equation of this line is written as
Substituting this into the general cubic curve equation , we get
By Vieta’s formula, any cubic of the form has roots that sum to , so here they sum to , or in other words
Plugging into the equation of the line above, and flipping the sign to reflect along the -axis, we get
So , which is one of the six points already in . In fact, similar to how multiplication mod a prime before had a generator , where gives all elements of the group, elliptic curves also have the same idea, just with addition. There is some point on the curve such that repeatedly adding to itself, , , , \dots, gives all of the elements of the group in the same way. We call a generator too.
In practice, isn’t chosen to generate all elements of the group, and instead only generates a large subgroup of prime order, as an efficient attack exists for non-prime order groups [1]. Now to tie everything back together. Say that I hand you a point on an elliptic curve, and another point , such that
for some integer . In other words, was added to itself times to produce . Could you tell what is from this information? No, or at least nobody knows how to do it efficiently.
Elliptic Curve Discrete Logarithm Problem (ECDLP): Given a generator on an elliptic curve, and a point , determine .
This is the same as the DLP from before (Discrete Logarithm Problem (DLP)), except in a different form. We have used a group built out of addition on an elliptic curve, rather than one built out of numbers mod a prime. The benefit of this new problem is that no known sub-exponential attack exists to solve it [1]. Therefore, we get the same security as before except with much smaller (256-bit) keys.
Why doesn’t the same sub-exponential attack that works on the DLP work for the ECDLP? Broadly, numbers mod a prime are still integers underneath it all, and integers can be factored. This has nothing to do with the group operation itself, but it’s still something that an attacker can use for solving the DLP, and is exactly what these sub-exponential attacks rely on [1]. When we first introduced groups, the group operation was multiplication. Factoring is really just multiplication in reverse, so even if the multiplication is done mod a prime, there’s something small to grasp on to and develop an (albeit still inefficient) attack. The coordinates of points on an elliptic curve are integers too. However, nobody has found a way to connect these integers to the elliptic curve group operation in the same way that factoring connects to multiplying integers mod a prime. This doesn’t mean that such a connection can never be found, but so far nobody has.
If you are curious, the specific elliptic curve Bitcoin uses is called , with the equation
where is the specific 256-bit prime [2],
which was specifically chosen because it can be computed very quickly using only addition and bit shifts.
The reason we trust any of this is that nobody has found a fast way to solve a small handful of specific problems, despite decades of people trying. There are a couple more concepts to cover before we actually talk about Bitcoin, but this is the math holding all of it up. It’s also the math a quantum computer breaks, which we’ll get to later.