Web Crypto 101, Part 1: Basic Encryption
--
Now and then, developing software both professionally and as a hobby, I have run into instances where I have needed at least a casual understanding of web security, the public key infrastructure, SSL certificates, or other related topics. Every time this happened, I was confused, worked to disentangle how everything worked, had an epiphany about how genius it is, then proceeded to forget it all. I am in the middle of another such cycle, so in order to not forget it — and to maybe help some others who are equally baffled — I am embarking on a small journey: a series of posts explaining the “cryptography” side of web security in as simple terms as possible.
Since this is the first, let’s look at the very basics: encryption.
What Is Encryption?
Wikipedia says:
In cryptography, encryption is the process of encoding a message or information in such a way that only authorized parties can access it.
Or, in other words, it is transforming a message in such a way that its original meaning is unclear and cannot be recovered except by someone who knows how to undo the transformation. For example, if Alice and Bob were kids who wanted to pass “secret” notes, they might agree to write backwards. That way, our gym teacher is really mean becomes naem yllae si rehcaet myg ruo which is totally unintelligible (right?). The one of them receiving the message knows to reverse it, but the other kids (or worse, the gym teacher) does not know that, so they are not party to the message.
Side note: in encrypting “in-transit” information, the general assumption is that the transmission medium (in this case, the kids’ note) is not safe; it could be intercepted and read by anyone. Encryption is employed so only the right people can understand what they’re reading.
Unfortunately, it’s not that easy. The gym teacher, at least, is almost definitely going to spot the trick. Alice and Bob are going to have to get a bit smarter. They need to establish a more complex cipher, a technique by which their encryption works.
Ciphers and Keys
One of the simplest ciphers is the Caesar cipher, in which Alice and Bob would have to establish a special number, replace each letter in their message with a letter occurring that number of characters later in the alphabet. For example, with a number of 4, they would replace A with E, B with F, C with G, etc. In this case, the number 4 serves as the encryption key.
The full cipher looks like this:
Plain: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Caesar-4: EFGHIJKLMNOPQRSTUVWXYZABCDThat means that, the message our gym teacher is really mean, encrypted with the Caesar cipher, with a key of 4, is syv kcq xiegliv mw vieppc qier. This will certainly get past the gym teacher.
Alice and Bob are not off the hook yet, though! Their math teacher is on to their Caesar cipher, and whips up a spreadsheet to crack the code:
By guessing different keys, Alice and Bob’s math teacher cracked the code! They’re busted!
A Few Steps Forward to Good Encryption
If Alice and Bob want their secret notes to not be easily discovered, they will need to get a lot more clever. Their Caesar cipher won’t be enough — it can only have 25 different keys, so checking all of them is trivial. To make it less trivial they will need a cipher with many more possible keys: billions, trillions, or more.
For that sort of task, their math teacher might need to help. There are standard encryption ciphers such as the Advanced Encryption Standard (AES) that offer far, far better security than a Caesar cipher. Not only do they obscure information better (completely scrambling the data, not just switching letters around), but they also offer a large number of keys to make cracking the code completely infeasible. In AES’s case, that means keys up to 256 bits long, or 115792089237316195423570985008687907853269984665640564039457584007913129639936 possible keys.
For a sense of scale, if you took a billion computers (already quite a task) using unrealistic 5 GHz processors with 32 cores (which don’t exist), and those computers could somehow use only a single processing cycle to try to guess a key (it takes a lot more than that), and you started trying to use this computer cluster to crack a single 256-bit key at the time of the Big Bang, you would only be 0.00000000000000000000000000000000000000000000006% finished today.
Caveat: The above is a gross oversimplification of the complexity involved in breaking encryption. There are more clever ways to crack an AES key, but none of the ones known at the time of writing make the task feasible.
So… we’re done, right? Alice and Bob can now pass mean notes about their gym teacher securely because their messages can’t possibly be cracked?
Not quite.
The Problem with AES
AES and similar ciphers have one big common problem. They are symmetric ciphers. That means they use the same key for both encrypting and decrypting information. That is not inherently a problem, but it does present a question: how can Alice give Bob the key safely?
The answer can’t just be “encrypt it”, since we need the key to encrypt stuff in the first place! The only reasonable solution is to assume they both have the key ahead of time, but for that they would need some special preparation. For example, they could meet the previous night on a street corner and pass the key. Something less out of a spy thriller would work too.
That solves their problem for now.
Let’s circle back to the premise of this blog post, though: web security. When they grow up, Bob may find himself shopping for vintage Pez dispensers online. He finds Alice’s Pez Emporium, and must enter his credit card details to finish a purchase. How can he do so securely? Neither he nor Alice can start communicating until they both know what cipher they are supposed to be using, and what key to use with it — but they have no way to securely share that information!
Remember: the communication medium is suspect. There are multiple points in an Internet connection where someone can snoop, and any information transmitted (including Bob’s credit card info, or any encryption key) may be compromised. It is simply not possible to use a symmetric private key cipher when the two involved parties have not had any prior contact.
For that, we need a way to handle things when keys are public. A “public key encryption” system, if you will. An explanation of that, however, will have to wait for the next post in the series.
Thank you for reading!
