How Encryption Works, and Why it Can't be Backdoored

It's time to learn about encryption.

Encryption is something we use everyday, when we connect to Facebook or Google or Twitter. We absolutely depend upon it when we log into our bank accounts online, our PayPal account, or the website of the Canada Revenue Agency to submit our taxes. For all these things, we're using HTTPS. You might know that "HTTP" stands for "HyperText Transmission Protocol". The "S" stands for "Secure" or "SSL", whichever you prefer. You also probably know that this protocol keeps your data safe from spying eyes.

You probably don't know the nitty-gritty of how HTTPS works. If you're curious, and you have a little patience, and you're willing to accept a slightly simplified version of the process, then I'd love to explain it to you.

"'Be sure to drink your Ovaltine.' Ovaltine? A crummy commercial? Son of a bitch!"

Let's say you have a Little Orphan Annie Decoder Ring. To encrypt a message, you look at a letter and number in your message and replace it with a corresponding letter or number as indicated on your decoder ring. Once encoded, the message looks like unreadable gobbledegook. The recipient can decode the message with their identical decoder ring by completing the process in reverse: use the mapping on the ring to determine each original character/number of the message. This is symmetric encryption in the most basic form: a simple substitution cipher (and not even remotely secure by even WW2 standards). An enemy spy who intercepted the message could crack the code simply by trying different mapping combinations until the message made sense. And today, when we have powerful computers to do such things for us, the task is trivial.

That's why modern cryptography ciphers are devilishly complicated, and constantly changing. For example, over the last couple of years Google has forced the rest of the tech industry to retire a set of cryptography ciphers called SHA-1 (by having Google Chrome tell people that their connections weren't secure if the website used SHA-1). It was annoying for us in the IT industry to make this migration, but also necessary.

That's because any encryption code can be cracked by a computer using the brute-force method (that is, just trying different combinations until something works) given enough time. So the main question is, how long will it take? Hours? Weeks? Decades? As computers get more powerful, it becomes quicker for attackers to decrypt things by brute-force. So, to keep our digital communications secure, we periodically have to upgrade to more complex algorithms, which will take prohibitively long for even our most powerful computers to decrypt by playing the guessing game.**

But going back to basics, the other problem with that Little Orphan Annie Decoder Ring (let's call it the LOADR cipher - acronyms!) is that it's symmetric. If you only want one recipient to be able to read your message, you're in trouble, because a spy with another LOADR could decrypt your messages if they intercepted them. What's more, that spy could destroy the original message, write a false coded message, pass it along, and your recipient would be none the wiser.

That's why we have asymmetric encryption, where two different ciphers are required. The first cipher can only encrypt messages, while the second cipher can only decrypt. With those concepts in place, let's walk through a typical conversation between two computers using HTTPS.

The Request

It's a new day, and you open up your browser to go to Catbook (because of course you do). The address begins with "https://", so your browser knows it has to start a secure session with the server "catbook.com". It calls Catbook and asks for the server's public certificate, which Catbook sends to your browser.

The Public Certificate

The public cert has a couple of functions:

a) First, it's cryptographically signed by a third party: a Certificate Authority (the CA). This basically says: "We, the CA, confirm that this is a valid, up-to-date cert issued by a real organization which owns the domain name you're connecting to." You can view this in your browser if you click on the little lock icon.

As you can see, Catbook has what we call a wildcard certificate for "*.catbook.com". Only Catbook can issue this cert to users, and only from servers whose domain name ends in "catbook.com". This provides the web browser lots of assurance that whoever it's talking to is actually who they claim to be.

b) The second thing that the public cert does is act as an asymmetric encryptor. Catbook  on their machines only, has something called the "Private Key". As the name implies, this is secret. Not even the CA who signed the public cert has the private key. The public cert can be used by your browser to encrypt a response, but no one can decrypt that response unless they have the private key (which, to stress, only Catbook has). If anyone intercepted your browser's response, they would only see unreadable gobbledegook. Only Catbook has the private key that's capable of decrypting it.

A Shared Secret

The encrypted response your browser sends is a randomly selected symmetric key: one that the client and server can use to communicate going forward. This key is what we call a "shared secret". Like the LOADR, it can be used to both encrypt and decrypt information. However, it's a way more complicated cipher than LOADR, and your browser and Catbook negotiated it in secret, so no one else knows it.

Secure!

From here on, your browser and Catbook can communicate securely and privately.

There's two key things you should take away from that explanation: authenticating identity, and the shared secret. The key exchange method varies depending on the connection type and purpose. Two devices might each generate a public/private keypair and send their public keys to eachother - whereby only the intended recipients can decrypt a message (by using their own private key). In any case, encryption is designed, from the ground-up, so that a message can only be read by the intended recipient.

So what happens when a government wants us to change these technologies so that governments and law enforcement can decrypt any communication?

There would be two ways to do this. The first way would be to CC the government on private keys: any time that any machine or program anywhere on Earth initiated an encrypted connection, they would send a copy of their negotiated private/shared key to a government server somewhere. Since there are likely hundreds of millions (if not billions) of connections being negotiated on the internet every second, this would be hilariously impractical.

The second possibility is if governments required us to change our cipher algorithms so that there is one key that can unlock any encryption, anywhere, any time. This is the utterly horrifying "master key" scenario. All it would take is for a malicious party to either steal or brute-force decipher that master key, and suddenly everything on the internet would be vulnerable. Criminals could spy on our banking, terrorists could penetrate our infrastructure, and griefers could terrorize our kids (more than usual, anyway).

The servers used by my employers only use encrypted connections to talk to eachother securely over the internet. The vast architectures of Facebook, Google, Amazon, Apple are all doing the same thing. Their servers are all administrated (by other sysadmins like me) using SSH or SSL-enabled RDP. All of those servers in turn use the HTTPS connections I've described above to talk to their customers' web browsers. Your email runs on TLS/SSL. The credit/debit pinpad you just used to buy that coffee? Encrypted TCP/IP. All of this stuff - which presently is reasonably secure - would suddenly be very vulnerable.

This would be the fundamental destruction of our technology architecture as we know it.

As an IT admin, I am filled with dread and fear in a way that I've never been before. I keep plugging away here on my little blog, mega-corporations like Apple and Google rail against the FBI, and computer scientists and security experts merely shake their heads in exasperation. I'm starting to fear that this is a losing battle; that the deliberate breaking of our entire security apparatus by legislators is just around the corner. As I contemplate the cataclysmic results of such an outcome, I'm reminded of a quote by the character Rorschach in Alan Moore's Watchmen:

"... Politicians will look up and shout 'Save us!'... and I'll look down and whisper 'No.'"

Thanks to How-To Geek for helping me to quickly brush up on some of my encryption terminology.

Screenshot from "A Christmas Story", property of MGM/UA Entertainment Co.
All illustration graphics made by Jesse Schooff. 

** It's worth mentioning that, in the case of the San Bernardino shooters' iPhone, the FBI wants to Apple enable a brute-force attack upon the phone's lock screen, bypassing the "fail ten times and the phone self-deletes" restriction. A brute-force guessing of 4-6 number passcodes could take mere days.