The Fallacy of a Safe Encryption Backdoor

For the past several years politicians around the world have attempted to put forth laws to require governmental means for seeing the contents of encrypted traffic. The claims for why this is important are usually some variation of the following:

• Combat terrorism
• Combat CSAM
• Combat espionage
• Uh, something else, probably

OK, really three straw man arguments. Admittedly, all three are laudable goals to be pursued. However, I want to focus on why such backdoors are a security and privacy risk to everyone because of the primary fallacy behind the concept in the first place.

A Brief Encryption Primer Without Actual Math

The Building Blocks of Encryption

Encryption, at its heart, is just really complicated math. (Sorry, there's no way to avoid math in encryption, but we'll simplify it for our purposes today) These math problems take at least two inputs and provide a singular output:

• The data to be either encrypted or decrypted
• A key - a "secret" number that needs to be included in order for the math to work

All parties in the encrypted conversation all have to be using the same math to do the encryption and decryption. That math - which is in truth a well tested and extremely complex equation - is commonly referred to as the cipher. There are a variety of ciphers that are accepted for encryption across the Internet, and are standardized to ensure that encrypted communication can work. Common encryption ciphers you may have heard of include AES, Twofish, and Triple DES. As time goes by some ciphers are no longer considered "good enough" to protect data, such as Triple DES, which hasn't been an approved cipher for Internet traffic since 2016.

In the simplest form of encryption, both parties use the same key for encryption and decryption, and this is called symmetric key encryption. This is a popular form of encryption because it is relatively fast to perform (because the math is comparatively simple). The problem with this style of encryption is that somehow both parties have to have the same key. So either both parties have to start the conversation already having that key, or they have to have a secure way to share that key with each other as they start the conversation.

To solve for the key exchange issue of symmetric key encryption, a more complicated solution has been developed. This system actually includes two keys for each participant in the communication:

• Private Key - a key that you keep for yourself and don't share
• Public Key - a key that you share openly with everyone

These keys are tied to each other in a way so that a message encrypted with your public key is ONLY readable when your private key is used to decrypt it. So if you and I are having an encrypted conversation the process would look like this:

1. I use YOUR Public key and encrypt a message to you.
2. You use YOUR Private key to decrypt and read that message.
3. You then use MY Public key to encrypt a reply to me.
4. I then use MY Private key to decrypt and read your reply.

This type of encryption is called asymmetrical key encryption, and is considerably more resource intensive to make happen. The key system that includes these public and private key pairs is commonly called Public Key Infrastructure (PKI), and the keys are sometimes called certificates - and that forms the basis of our SSL and TLS communications on the Internet today.

Encryption In Practice

In a typical encryption scenario, such as you visiting this website and reading this page, both encryption methodologies are employed. The process looks something like this (though this is a simplification and not exactly the steps in a TLS handshake):

1. Via "clear-text," your browser shares its public key (unique to you, your browser, and this particular session) with my webserver, and my webserver shares its public key with you.
2. We propose and agree on ciphers, still via plain text.
3. Your browser encrypts a random number using MY Private key, and sends it to my webserver
4. My browser decrypts that random number. We then both use that random number to generate the symmetric key we'll use for our session. We may have several sessions throughout the course of our conversation, depending on some rules that go with the cypher chosen and other parameters.

This method is commonly used because it balances the difficulty of agreeing on a symmetric key over publicly viewable channels, and the extra overhead of just using asymmetric encryption for the whole conversation. This process is also the basis of encryption for end-to-end encrypted (E2EE) communications between peers: PKI keys are used to protect the generation of session keys that are symmetrical, and then those keys are used for the communication. There are authentication steps that asymmetric encryption and PKI offer as well, but those are outside of the scope for this conversation.

How a Backdoor Would Impact This Process

As a practical matter, there are only so many way a "backdoor" could be implemented in this process. The idea that lawmakers seem to have with regard to seeing encrypted messages is to modify the encryption process itself to allow for a "master key" that they would control. The theory is that as they're monitoring specific comms they some how come across a particular encrypted communication they need to decrypt with their master key.

As already stated, encryption ciphers are extremely complex equations. Well, it happens that there have been many attempts at creating ciphers over the decades. Only a few have functioned well enough to be approved as encryption ciphers because of all the requirements of an encryption cipher. The first hurdle of a "backdoored cipher" would be somehow adding this new "master key" functionality without otherwise preventing the cipher from working properly. The additional complexity in the math would be extremely intense.

Ciphers are also, as it happens, open sourced. They have to be, because everyone in the world has to be able to use them. I'm not sure how you hide a secure "backdoor" in a publicly scrutinized math problem, but I digress.

Even assuming a new cipher can be developed with a "master key" that a government (which government? Do we now have to use different ciphers depending on which jurisdiction we are in? How many backdoors does this cypher have to have?) can use to instantly decrypt any message, the amount of time between the announcement of that cipher and finding out that the master key has been stolen by a malicious actor will be measured in milliseconds.

The upshot of this model - which seems to be the one world leaders somehow support - is that it breaks encryption, full stop: any "master key" based solution simply means that whoever ends up with the master key can read encrypted traffic, and we cannot assume that such a key would be kept securely by benevolent and wise keepers - government or otherwise.

The Other Option That Doesn't Work

The alternative proposal that often shows up to do this same task is to require "on device" reading of messages before/after they've been transmitted securely. In other words, either having software installed on your phone/computer/etc. that scans all your communications and decideds if it is suspect or not. Suspect data would then cause some form of response from sending a copy of the communications back to a government collection system to calling down law enforcement to your location immediately. Think about the sorts of monitoring you'd expect from certain countries around the world who tend to oppress their citizens. If you ever look at these laws carefully you'll note that they always have exemptions for, well, for the people who influenced the law to not have their data scanned.

The Wrong Tool To Combat Serious Problems

This approach is simply an Orwellian fever dream of people who don't believe privacy should be enforceable. As a practical matter, such measures aren't efficient means for combating any of the problems this is purported to solve. Just as I would reach for a hammer instead of a screwdriver to pound in a framing nail, this is a case of trying to solve a problem with the wrong tools. Even worse, this would dramatically decrease privacy and security for nearly everyone impacted by it, including those already at risk who need to have secure, private communications channels.

One of the biggest issues in combating this idea is that when a bill comes up to introduce this backdoor idea it usually comes to the floor with a name like the "Combat CSAM Act" or the "Protect Our Children Online Act." These are the Trojan Horse names by which this concept makes it to legislative floors, and it has happened regularly in the US since at least 2016, making it difficult to oppose this bad idea while explaining why you're not FOR harming children, etc. Hopefully this blog helps us all with that explanation.