All of us have those angels (in the form of people) in our lives whom we can share almost anything with. We choose to place immense trust in them. However, is it only them that we place our trust in while sharing our deepest secrets?
I like to imagine that there are people out there who consider me to be one of theirs. I take pride in the fact that they choose to put that trust in me.
Technology advances faster than we can keep track of it. And this comes from someone who is trying his best to follow it. Information transfer has never been as instantaneous as it is today in human history. We have like a bazillion mediums to communicate with each other. But are we supposed to trust them blindly, even with our deepest of secrets (the ones we would only share with our angels)? What happens if an intern in one of those companies presses a button revealing them by mistake? Am I supposed to just take it at face value that the required controls are being followed when the incentive for the same is negligible with the monopoly some of these apps possess?
I am not the only one frantic about this concept. The life of Edward Snowden is an interesting case study for the skeptics. There’s also a film about Snowden! Moreover, in this video Tristan Harris has a few compelling reasons to give weight to my doubts on the unwavering trust we keep on technology.
Okay, don’t get me wrong here. Not all conversations are really that private that I want them to be protected like it’s a national treasure (supposedly even that’s not safe enough). But a few of them really are. A select few should simply never become public. And that is the point here, not your everyday grocery shopping list that you share in the household!
In an ideal world, I would rather have a mechanism to ensure that perfect secrecy is guaranteed when I want it. That no one apart from the intended person has access to read this. Thankfully, I have a degree in Computer Science!
Before you switch tabs, hear me out once. I am not intending this to be a comprehensive technical article. In fact, quite the opposite. I want you, the reader, to develop some intuition for the concept before I reveal my true intentions. Like always, I leave the gory details to the experts. I don’t intend to replace them. Moving on.
I first learnt about Cryptography when I was in university and I was fascinated by the concept. It demonstrated how two people can communicate a secret with each other publicly without worrying about others prying on them. Take a moment to appreciate the intimacy in that. A parallel to that in traditional conversations would be that two people are talking to each other from across the room, everyone in the room being able to hear them, yet only the intended people decipher the conversation. Almost like they are speaking an alien language!
The concept of protecting something that you don’t want others to know/see/hear hasn’t changed since civilisation really. We have just gotten better and better at it. It’s simply…locks. Have one lock and two keys, keep one with yourself and give the other to your angel, and voila! Now you understand Encryption (locking) and Decryption (unlocking). Sure the fancy scientists have just found clever ways of locking only to increase confidence. How do you do that? Simple ask people to solve a hard Math problem 😉. That’s enough to scare them away supposedly.
Let us be a bit more specific with the whole “hard problems” though. When I say “hard problem”, I don’t mean that the problems that you and I can’t solve (that’s our skill issue btw). We’ve all had that one smart person in our class/group. The person who always came first when it came to Math. Now give that person the world’s best supercomputer. Even with that if our beloved topper is not able to solve the problem in our lifetimes, now that is a hard problem. The cool computer scientists like to call these types of problems as intractable problems, as opposed to tractable which can be solved efficiently by a computer algorithm fast enough that we can see the answer. Now you can piece together why behind every secure lock, i.e. Encryption algorithm, lies a hard problem to solve.
So our universe looks something like this now:
Folks, Bob isn’t smarter than us. He cheats. He possesses a secret piece of information, a trapdoor, that turns the seemingly impossible problem (to others) into an easy one for him. If we look at the picture from the perspective of hostile land residents, they are only able to see the encrypted message. An encrypted message is usually gibberish. Literally something like: s24a2425lhjfb442al. Pretty useless for them. Alice, on the other hand, has a mechanism to encrypt the message and knows that Bob has a trapdoor for it. So she converts her meaningful message into the gibberish and sends it over to Bob, and Bob decodes it (which only he can do!). That’s essentially it.
This is where I have taken some scientific liberty. So cryptographers, don’t condemn me to hell. Almost all of the article is written with public key cryptography in mind. So my dear reader, symmetric encryption works differently and doesn’t fit this trapdoor analogy. But honestly, it isn’t relevant to me here, so I’ll happily leave that rabbit hole unexplored.
There is another interesting trick hiding in this picture. Remember that Bob possesses something nobody else does: the trapdoor (or his private key). So, for a moment, remove Alice from the picture entirely.
Bob can intentionally send the original message along with another piece of gibberish generated using his private key. Now, anyone in the world who has Bob’s public key can check whether that gibberish could have come from Bob. The interesting part is that while everyone can check it, nobody else can produce the same kind of valid gibberish for a different message because they don’t possess Bob’s secret. In cryptography lingo, we call this signing and verification. Bob signs; everyone else verifies.
Take a step back here and notice something very human hiding underneath all of this. This is someone convincing you that they really are who they claim to be. They possess something no one else does. So when a message arrives claiming to be from your angel, you don’t simply have to take its word for it, you have a way to check that it really came from them.
I want to take a look, and just a look, at what sort of math problems, are the cryptographers really using. After all, that is the entire spirit of this article right?
That said, I do not get into the nitty gritty of the math. I want to keep it simple in this section. I keep the complicated details for the last (optional) section.
RSA, named after the heroes who invented it, is based on the hard problem of factoring large numbers. If I give you two prime numbers, let’s take 7 and 13, their product is easy to calculate, 91. But if I give you 91, and ask you to give me the two numbers back, welp, that’s a hard problem. I sense some eyebrows raised? Replace 91 with a 617-digit number then. Those are the sort of numbers even computers start sweating on. On top of that, we get arithmetic clocks involved too (i.e. after 12, the clock goes to 1 instead of 13). Looking only at a clock showing 3 tells you where you are on the clock, but not how many times you went around it to get there. Remember, the key idea here is that reversing the operation should be extremely time consuming. RSA cleverly leverages both of these ideas to achieve exactly that.
ECC, Elliptic Curve Cryptography is slightly more geometric in that regard. Where RSA just used a clock, ECC folks decided to run wild with that idea. They say, why not throw a curve like this into the mix instead:
The point of ECC is still the same: make something easy to do in one direction and painfully difficult to undo. I know this probably sounds wild if you haven’t seen it before, but we can define a strange kind of addition between points on this curve. Add a point to itself enough times and you eventually land on another point on the same curve. So, starting with a point P, we can calculate 2P, 3P, 4P and so on. Now here comes the fun part: give a computer P and some gigantic number k, and calculating kP is easy. But give it P and the final point kP, and ask it to figure out what k was… well, our beloved topper might start sweating again.
RSA and ECC each have their advantages, but one particularly attractive thing about ECC is that it can provide comparable levels of security using considerably keys smaller in size. Why mention both of these to you, my ravenous reader? When we are generating keys, we generally have both these options available:
And now those names aren’t just mysterious acronyms in a dropdown anymore. You have at least some intuition for what is hiding underneath them. RSA: a game of enormous numbers and factorisation; ECC: a game of points on strange curves. If you are even mildly curious about the actual math under the hood, stay tuned! In the last section, I want to take examples and drive the point home but I decided it would be too heavy to mention it here itself.
For everyone else, let’s come to the point now.
The world works on layers of abstractions. There is no denying that. After all, when you are sending a message to your angel, you really don’t care about whether you are using ECC or RSA. You do not need to know how an IC Engine works to operate a car. Similarly, you do not need to know the gory math behind cryptography to start using it. Here is where OpenPGP makes its entry.
The history of (Open)PGP is itself wild. You would assume so too. After all, it gives individuals more control of their privacy. PGP stands for “Pretty Good Privacy”. It was first developed by Phil Zimmermann as a tool for ordinary people to protect their privacy and civil liberties, before eventually becoming a commercial product. However, the ideas and formats of PGP gave rise to OpenPGP, an open specification that anyone is free to implement. Therefore, there are various OpenPGP tools available, many of them compatible with each other. From here on, when I say PGP, I am referring casually to the broader OpenPGP ecosystem rather than Zimmermann’s original software.
Here’s my public PGP key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEapPCnRYJKwYBBAHaRw8BAQdAUtBSFlNzeaWm5YaAmrt7Ssd26acWqR6O
NPVmXB5jphbNJlByYW5hdiBDaGF0dXIgPHByYW5hdkBzdGlsbGFueXdheS5j
b20+wsATBBMWCgCFBYJqk8KdAwsJBwkQXy4/atDBJgNFFAAAAAAAHAAgc2Fs
dEBub3RhdGlvbnMub3BlbnBncGpzLm9yZyzivcZbD8Z/NyP7dD9hx2+1LXHZ
Iue8EUMbLbXxlCjKBRUKCA4MBBYAAgECGQECmwMCHgEWIQTdGiUXvuzyZ6r+
X4VfLj9q0MEmAwAAQiABAJpZ4pCPus34yL5kdICbbANSMxlvXukjuBBBfFFP
S5NoAP9U7/bZwrbeb7EbjyGcR8sPgShAKtORT7kOhzmCy8csA844BGqTwp0S
CisGAQQBl1UBBQEBB0BffBh88uDiIQ9xGv7Bp+ihsHwV8rnTyS4s6NM4an0/
FQMBCAfCvgQYFgoAcAWCapPCnQkQXy4/atDBJgNFFAAAAAAAHAAgc2FsdEBu
b3RhdGlvbnMub3BlbnBncGpzLm9yZ8qzlpKx9EOnzVBQRBxZAA1JQERHc5nW
BY2aNQWmdypaApsMFiEE3RolF77s8meq/l+FXy4/atDBJgMAAAe8AQCzDPcT
6gH4KtZjkt5YHPzU3IVD/volf7b3R5O3J+YagAD/eR2TUJIbYgIzlSb2/UdT
/N4GGn431QSNDpRjfXNzSgQ=
=0v2O
-----END PGP PUBLIC KEY BLOCK-----
We are finally mature enough to understand, appreciate and utilise this behemoth now. Note that this actually is my public key, not an example for demonstration purposes! What follows is a walkthrough on how you can use it. Don’t worry! I’m not going to make you do factorisation or curve multiplication…just a few button clicks here and there. That’s how hard it is to protect your privacy when it matters!
There’s a plethora of tools available which are built on top of OpenPGP. Below I list them out based on the different environments you are in:
I’ve personally verified the UX of each of these tools, and honestly, none of them are particularly difficult to use.
But.
Given the spirit of this article, it only felt fitting that I build Yet Another PGP tool of my own. Not because the world desperately needs one more, and definitely not because I think mine is the best. YaPGP exists because I wanted to carry the same principle we started with all the way through: as few middle-men and moving pieces as reasonably possible.
So YaPGP is deliberately boring. It is open-source, built with minimal code, and does as little as it needs to. Your cryptographic operations happen locally, your keys stay with you, and there is no account or server that needs to sit between you and your angel. The goal is to stay as close to OpenPGP itself as I reasonably can while hiding enough of its complexity that even someone with no technical background can use it.
Also remember that I don’t want you to trust YaPGP because I tell you to. In fact, that would rather defeat the point of this entire article. The source is there for anyone who wants to inspect it, and the cryptography underneath follows an open standard rather than something I invented myself.
By default, I have loaded my public key into the tool (although you can use your own too!). Here’s a quick example of how you can encrypt a message before sending it to me:
Similarly the process of verifying my words is also pretty simple. Take the following message as an example:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
This is a small cryptographic way of saying that my words are mine, and that I am willing to stand behind them.
-----BEGIN PGP SIGNATURE-----
wrsEARYKAG0FgmqTxBsJEF8uP2rQwSYDRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmebsTkqbzkZZ7zTViu1oPOj0c+0oSl22Lwiewx1
RCKK5xYhBN0aJRe+7PJnqv5fhV8uP2rQwSYDAAClPAEA3hCxTgarD8bi9PQe
0pHMn9a9nVQqz+o7ApSCjt/ZLQ4A/RgS3+gzXi2qxN55Kmh1SpUDTj0UVjRn
PfEFgommoOsA
=8k//
-----END PGP SIGNATURE-----
You can paste the entirety of this block in the “Verify” tab to confirm that I was the author of those exact words!
My intention of developing YaPGP (or any of the above-mentioned tools) is to provide you, my angels, a way to reach me. You do not have to trust the middle-men carrying your message with its contents. Your secrets would be safe with me. I have the power of cryptography by my side to protect them. At the same time, you will also be able to confirm that a message claiming to be written by me is actually written by me and is unchanged since. As my signed message said, it is a cryptographic way of saying that my words are mine, and that I am willing to stand behind them.
There is a small issue here. As it stands, you, the reader, can use my public key to send me an encrypted message, which I can decrypt. But I don’t have your public key! So I can’t send you any encrypted messages!
Maybe it is time for you to start holding your keys too!
All the tools mentioned in the previous section support key-generation. So does YaPGP! You can check out the “Generate” tab. Once you generate your keys, remember to store them somewhere safe. Never reveal your private key to any individual under any circumstances!
For the skeptics who are uninterested in understanding JavaScript code: I am using the OpenPGP standard via OpenPGP.js, which generates keys with Elliptic Curve Cryptography, the Ed25519 curve for signing and the X25519 curve for encryption.
Consider this as a special plea to the people who I consider my angels. You know if you are one of them. If you are reading this, let’s get you your PGP keys! In case you need help, feel free to contact me. You know how to reach me! Also, remember to share your public key with me. I’ll have it stored for the moments when I want to feel vulnerable to you and you alone.
Not just for YaPGP, and not just for my angels. If you are a random passerby who somehow ended up making it this far and still find yourself pondering about PGP, I would encourage you to generate a pair of keys of your own. Maybe you would lose the keys before using them. Maybe you would never use them at all. Maybe some of your secrets would be lost forever. But just having them means that when a moment comes where privacy truly matters, you already possess the means to protect it. Perhaps share your public key with the people you trust too. Give them a way to reach you without having to trust everything that happens in between.
Ultimately, saying that you don’t care about privacy because you have nothing to hide is no different from saying you don’t care about freedom of speech because you have nothing to say. — Edward Snowden
In today’s post-truth world, one of the most important decisions we make is deciding whom to place our trust in. Through this article, I want to make a case for placing a little less of that trust in promises, and a little more of it in cryptography. You can come from any ethnicity, country, religion, culture, age-group, have differing opinions on political regimes, economic structures, dietary preferences. Computer Science does not discriminate against you.
It is symmetric.
As promised, we dive a level deeper into the math behind RSA and ECC.
We know that the intuition behind RSA is factorization and modulo arithmetic. Let’s take our example of 13 () and 7 (), the two primes in contention. Therefore, , which is going to be part of our keys! (remember and are always kept secret). So now imagine a clock with 91 numbers (instead of a standard 12).
Now, here’s the first trick behind RSA, the Euler Totient, which is . What does this give us? The number of co-primes to . The intuition behind this totient is simple, there are exactly 13 multiples of seven and 7 multiples of thirteen which share a common factor with . This totals up to 20 19 numbers on the clock of digits (we counted “91” twice). That is exactly . As an exercise, we can literally list them down, but I’ll skip, hoping that the point is clear. Essentially, the totient function tells us how many numbers can move freely around a modular clock without sharing factors with the size of that clock. This is needed for the next step.
Now, as the next step, we need to choose a number , which is co-prime to , i.e. . Let us take . This is going to be the public key along with , i.e. . Now, our private key , where is a number which is modular multiplicative inverse of our public key, i.e.
In other words, we are looking for a multiple of that is exactly one more than some multiple of 72. There is an algorithm for this, but for the sake, I give you the answer, our .
So our private key is therefore
Well, these don’t look like keys to me, I hear you asking! Fear not, my concerned comrade . Let’s say that you want to send me a message, . Generally, this message is encoded into an integer (because everything is!). The encryption strategy you would follow is
Now, this is the ciphertext, i.e. the gibberish that all the world sees. Now you send over to me. Remember that I have which no one else in the world has. So I perform following operation on the received message
So in case of our example it would be (assuming is coprime with 91)
So therefore I get , your decrypted message. That my friends, is RSA in a nutshell.
Of course, real RSA uses absurdly larger primes ( is almost always ), proper message encoding and padding, and a few other details that I am very happily sweeping under the carpet. But the underlying trick is now visible: choose two secret primes, exploit the repeating structure of modular arithmetic, publish one exponent, keep the other secret, and construct them so that what one does, the other can undo.
Let’s talk about our curve first. A commonly used form of an elliptic curve looks like:
where and are parameters that define the curve.
There is one important detail though. The pretty continuous curve that I showed you earlier is useful for building intuition, but actual cryptography does not operate over all the real numbers. Instead, we work over a finite field. In our toy example, that essentially means throwing our modular clock back into the equation:
So rather than an infinitely smooth curve, we end up with a finite collection of points whose coordinates satisfy this equation. For our purposes, let’s take a hilariously tiny and completely insecure curve:
One point that lies on this curve is (We can verify this by plugging in the values for and )
Now comes the strange part. We can add points on an elliptic curve. If we were looking at the smooth curve from earlier, the geometric intuition is rather beautiful. Take two points and , draw a straight line through them, and that line intersects the curve at another point. Reflect that third point across the x-axis, and we call the resulting point .
If we want to add a point to itself, i.e. , we instead draw the tangent to the curve at . Let’s calculate . For point doubling, we first calculate a value called :
For our curve, , and since :
Nice and convenient.
The coordinates of are then:
and:
Therefore:
Yup, so here we are, after some elementary math, we just “added” to itself and somehow ended up at . I am going to spare you from repeatedly doing this algebra because the point here is not to turn this appendix into a mathematics exam. If we continue adding to itself, we get:
This repeated addition is what we mean by scalar multiplication. Suppose I secretly choose . Starting from the publicly known point , I calculate:
Going forward is easy. If I know and , calculating is efficient. The interesting question is what happens if I give you only:
and ask you to recover the value of such that:
For our ridiculous little curve, you could obviously just try until you eventually discover that . Real elliptic curves, however, operate over groups so enormous that doing this becomes computationally infeasible. This is called the Elliptic Curve Discrete Logarithm Problem (ECDLP).
In other words: is easy, while: is hard. And now our keys begin to emerge naturally. The secret scalar can serve as the basis of our private key, while the resulting point can be made public.
Conceptually, this is the same game RSA was playing. Construct an operation which is easy to perform when you possess some secret information, but extraordinarily difficult to reverse when you don’t. However, as mentioned, ECC beats RSA as it requires a smaller key size, reducing storage and transmission requirements. For example, a 256-bit elliptic curve public key should provide comparable security to a 3072-bit RSA public key.
Goes without saying but this tiny curve is only meant to build intuition for elliptic-curve point arithmetic. Real cryptographic curves are vastly larger and come with many additional details that I am very happily sweeping under the carpet.
And that is really the point of this appendix. I can be brutally honest and admit to the fact that even I struggle to do some of the involved Math (Chinese Remainder Theorem and Carmichael function for RSA, the finite field operations and point counting algorithms for Elliptic Curves). But looking at the machinery just a level deeper, it is evident that RSA and ECC might take very different mathematical routes, but both rely on the same broad idea, i.e. make something easy to compute in one direction and painfully difficult to reverse without the secret. This, I am willing to rest (my article) with.