Trivially Defeating Crypto Backdoors: You Can’t Stuff The Crypto Genie Back Into The Bottle

Why The Cryptographic Backdoors Law Enforcement Seeks
Are Worthless Against Any Minimally-Determined Adversary

Published in

The Startup

10 min readMar 23, 2020

Law enforcement claims that encryption backdoors would prevent the exchange of messages they couldn’t intercept and read. I call “bullshit!”

What law enforcement is trying to sell politicians and the media, is pure unadulterated snake oil. Law enforcement’s “backdoor snake oil solution” to their “encryption problem” is equivalent to — and just as effective as — all the purported “Cures for COVID-19” that are currently hyped on the Internet.

Their purported “need” for encryption backdoors is purely and simply a barefaced lie. There’s no other civilized way of putting it. Backdoors are neither necessary, nor will they solve the alleged “encryption problem.” Worse, backdoors will critically compromise everyone’s security.

And, if law enforcement actually believes that backdoors will solve their “encryption problem,” then they must be smoking too many of those left-handed cigarettes they’ve been confiscating.

Else, they’re totally clueless when it comes to encryption.

I’m not certain which of these two possibilities I find more frightening.

If you give it any thought, you have to conclude that law enforcement doesn’t understand crypto.

Why do I make that claim? Because of how easy it is to defeat the crypto backdoors proposed by law enforcement! It should be intuitively obvious to anyone with only a minimal understanding of the basics of cryptography that the proposed surveillance methods are all trivially defeated.

I’m certainly no expert, and it took me less than a microsecond to conclude that law enforcement’s proposals are, at best, moronic, and, at worse, disingenuous.

Before I dive into some technical details, please note that nothing I discuss in this paper is anything new, nor is it anything secret. Anyone with even minimal knowledge of cryptography should already know everything I state herein, and could probably tell you twenty ways to do what I describe in this paper easier, faster, cheaper, and more securely.

So, why is law enforcement wrong?

Because even a reasonably intelligent third-grader could be taught how to create and send encrypted messages which law enforcement would be unable to read. And do so using any of the standard messaging apps, such as Apple Messages, Facebook Messenger, Snapchat, WhatsApp, Telegram, WeChat, Discord, etcetera, etcetera, etcetera. And do so, even if those messaging apps, and/or the crypto they use, and/or the networks they use, were backdoored by law enforcement.

For example, using the free ‘openssl’ software, anyone can encrypt anything, such that it could not be read by law enforcement. Using the command line on any computer with openssl installed, here’s how:

$ openssl enc -aes-256-ctr -out my.msg
enter aes-256-ctr encryption password: 
Verifying — enter aes-256-ctr encryption password: 
Attack at midnight
^D Explanation:
$ is the command prompt
Then you enter your very long passphrase
Then you reenter your passphrase
Then you type your message (one or more lines)
^D indicates the end of your message

Now, the file ‘my.msg’ can be sent to someone who knows the passphrase used to encrypt the message, and only they will be able to read your message. (This assumes you have a very strong [long!] passphrase, and that law enforcement hasn’t compromised the passphrase, or your or your recipient’s computers.)

However, given the length of the message, anyone intercepting the encrypted message may be able to infer its contents. So, you could always obfuscate the message by burying it in random garbage, such as:

17paprwwfuagbm3ctwnndyuzdxh66zkbwpk0avtp2wgbqgcxlkqyc48fva6rkpcy9
fmpAzgcszhTwzrxkf4rTlhot3gAcdpqgv0fClraea2d1omselndqurvKjo7sqdhke
qocjvdkkzygzncbmxovy9x1f3b/meyeggdxskm7jwztlggud2vvA8wsdi+ioTomcv
egf5l6plupyd7dMjprn5hztatrIhe/sg5ehDNrz0gnlzhp9I9+kGe5cwpHdp+qjTo
7xq9zd2ugz5r1hhljcg/g5ovv3oedb0hcr3lxq87juxsppv8hdiajgpufbkcsos+0
^D(In case you don’t see the pattern, the message consists of the upper-case text characters.)

Location, Location, Location

If you wish to remain completely anonymous, sending messages through mobile devices creates a problem: law enforcement will always know your location from cell towers. So, let’s look at an example that not only will secure your message from law enforcement’s scrutiny, but which will also hide the identities and locations of the communicating parties.

Let’s pretend I’m a determined “resistance fighter” who needs to communicate in secrecy with another member of our underground. How can our resistance network communicate in secret and be as certain as possible that the locations of the communicating parties (whom I’ll call “Alice” and “Bob”) are not be traceable or identifiable? It’s actually a lot easier than you’d think.

Here’s all each communicant would need:

Four different VPN accounts, each from a different vendor, who:
◦ accept crypto-currency payments,
◦ support industry-standard VPN protocols,
◦ run VPN servers with no logging, and
◦ have had their security practices independently audited.
A firewall and a router that supports at least at least one (and preferably, two) of your VPN vendors’ protocols (e.g., IPsec, OpenVPN, WireGuard).
A host computer with a guest VM.
Open-source crypto software (e.g., openssl).
Open-source compression software (e.g., zip, gzip, etc.).
Open-source encrypted container software (e.g., VeraCrypt).
Open-source tor-based messaging software (e.g., Ricochet).
An out-of-band means of establishing tor-IDs and shared encryption passphrases.

In this discussion, I’m assuming that the firewall connects to the Internet, the router connects to the firewall, the computer connects to the router, and all connections are via Ethernet (no WiFi!!). I’m also assuming that the computer and its guest VM are both hardened clean minimal installs of your favorite operating systems, and are free of malware and spyware.

To begin, set up VPNs on your firewall (first) and router (second) and create VPN tunnels to any server of your choice. Each device should use a different vendor’s VPN service and tunnel to a different locale.

Next, set up the VPN on your computer using a third vendor’s VPN service, then establish a tunnel to a convenient server. (A quick point about operating systems: You should either use an operating system which doesn’t “phone home” on boot, or block all “phone home” attempts with your network and host-based firewalls. You do not want to accidentally disclose your identity or location, through O/S “features” which create unwanted network connections!)

Now, on your computer, you need to create an encrypted container large enough to hold your encrypted VM. Then, build the VPN outside of the container, encrypt it, and move it into the container. (You can build it in the container, but it may require a container about two-and-a-half times larger than the VM in order to encrypt it.) Next, set up the fourth vendor’s VPN on the VM and establish a tunnel. Now, download and install a tor-based messaging client and obtain your tor-ID.

At this point, you need an out-of-band method of providing your tor-ID to whomever you need to communicate. Lots of ways exist for accomplishing this, and I’m not going to iterate the possibilities here. You also need to establish a means of generating shared encryption passphrases if you want to send more than simple text (the example app only sends text).

Once everyone has everything needed to communicate, share a simple “test” text to verify everyone’s functionality.

When everyone agrees that everything works, it’s time to go to production mode. That means, for every message session (i.e., send and receive a related set of messages), you’ll want a completely different VPN configuration. That is, you should change the countries used for each vendor’s VPN servers.

For example, in the first messaging session, Alice could connect her firewall to a VPN server in Switzerland, her router to a VPN server in Iceland, her computer to a VPN server in Andorra, and her VM to a VPN server in Costa Rica. Bob could connect his firewall to a VPN server in South Africa, his router to a VPN server in Argentina, his computer to a VPN server in Bulgaria, and his VM to a VPN server in Luxembourg.

That means Alice’s tor network connection would originate from Costa Rica and Bob’s from Luxembourg. Thus, for Alice to send Bob a message, it would route from Alice’s (“hidden”) location to Switzerland, to Iceland, to Andorra, to Costa Rica via VPNs; then route over the tor network from Costa Rica to Luxembourg; then route via VPNs from Luxembourg to Bulgaria, to Argentina, to South Africa to Bob’s (“hidden”) location.

Yeah, the connection will be slow, but so what? The connection will be very difficult to impossible to trace if configured properly. And, you’re only sending text messages — so, so what if it’s slow?

To further harden your messaging system against snooping, every time you wish to send a new set of messages, reconfigure your VPNs through different countries. Just remember to practice good operational security, and have no upstream systems online unless all downstream traffic is fully encapsulated.

Also, use these systems only for sending and receiving messages, and nothing else. The less they are used, the lower the probability of compromise.

Sending Non-Text

What if you want to send something other than text?

The first thing you’ll want to do is compress whatever it is you wish to send. For example, using ‘zip’ utility, I’ll compress the ‘map.png’ file I wish to send, using the command:

zip map.zip map.png

That produced the compressed ‘map.zip’ file, which I’ll now encrypt with openssl using the 256-bit AES counter mode cypher. The following command specifies the cypher, that I want the output to be base64-encoded text, and that I want the output stored in a file ‘msg.txt’:

openssl enc -aes-256-ctr -base64 -in map.zip -out msg.txt

The text file, ‘msg.txt,’ can now be copied and pasted line-by-line into the text tor-based messaging app.

Yes, this is a rather brute-force approach, but it works. More importantly, it shows that even with backdoors into networks or devices, it is still possible to make them difficult to attack.

Using a defense-in-depth approach will make these systems even harder to attack. For example:

Using a different vendor for each VPN tunnel defends against a vendor being compromised. (Even better, use different VPN protocols and/or encryption for each different vendor’s tunnels.)
Using a different hardware vendor for your firewall and router defends against a manufacturer being compromised.
Using a different O/S for the host and guest systems (e.g., macOS for host, Linux for guest) defends against O/S bugs and compromises.
Using host-based firewalls (e.g., LittleSnitch for Mac, iptables for Linux) can further harden your systems by blocking all network traffic not sent by your messaging apps. (A properly configured host-based firewall should also be capable of blocking traffic originating from most compromised devices, too.)
Using an encrypted container defends against the discoverability of your messaging system.
Using an encrypted VM defends against the discoverability of unencrypted data, passphrases, and keys.
Placing the encrypted VM in an encrypted container potentially provides plausible deniability and definitely provides for an “impossible to recover” wipe of your messaging system.

An “impossible to recover” wipe of your messaging platform in an encrypted container becomes as simple as overwriting the encrypted container’s header with random garbage. And, it’s easy to make wiping undiscoverable.

Begin by creating a RAM-disk for your wipe script. When danger approaches, execute the wipe script (which destroys your container’s header and syncs your virtual disk), then force power-off your computer (hold down the power button).

Cutting power destroys the RAM-disk. When the computer is rebooted, there’s no evidence the RAM-disk or the wipe script ever existed (that is, assuming you have CLI history disabled and your swap is encrypted). And, there’s no evidence your encrypted container ever existed, either (assuming you don’t save it as a “favorites” and disable container history logging).

Of course, this all depends on good OpSec. Minor mistakes can compromise even the most secure and paranoid organization. Always exercise due care if you’re serious about security!

(And, if you ever suspect that you’re being monitored, you can always troll law enforcement by Alice sending Bob a troll message such as “fully prepared for <insert major city name here> smallpox release tomorrow at noon” — which would undoubtedly trigger a very public reaction by law enforcement. Then, you’ll know you’ve been compromised.)

Cryptographic Backdoors Also Compromise Security

Let’s drop the issue of backdoor effectiveness for a second, and examine a critical problem any cryptographic backdoor would create. And, that is that crypto backdoors compromise the security of any device (or network) with such a backdoor. It is impossible to create a backdoor “only usable by law enforcement.” Any backdoor present in cryptography will be broken by skilled attackers: it would not be a question of “if” but a question of “how quickly’”the backdoors would be broken.

When a nation-state breaks a cryptographic backdoor, at a minimum, it gives them the ability to monitor all communications occurring using that backdoor technology. In all likelihood, it would also provide them the ability to compromise at will any device communicating using that cryptographic backdoor.

Other authors have explored this issue in detail. I am only noting it here to point out that besides not providing law enforcement with the ability to break all encrypted communications, backdoors would also fatally weaken the security of everything they touch.

Do we actually want to provide every nation-state the ability to monitor the entirety of the world’s communications? I can guarantee you that would be the result of mandating cryptographic backdoors.

Summary

The crypto genie’s magic has been public for decades now. There’s no going back. Any attempt to backdoor crypto — such as has been proposed (demanded?) by law enforcement — can be easily thwarted. As I’ve shown here, cryptographic backdoors can be trivially subverted by even unskilled users given a few crypto tools and a minutia of training.

What law enforcement is trying to sell to politicians and the media, can only be described as a vast vat of snake oil. Contrary to law enforcement’s contention otherwise, and as has been demonstrated herein, encryption backdoors will fail to provide a means of breaking all encrypted messaging.

Any backdoor which law enforcement may mandate can be easily thwarted by even unskilled users. Worse, any backdoor present in cryptography can and will be exploited by skilled attackers to compromise devices and networks where the backdoor is present.

In my professional opinion, law enforcement is simply being lazy and cheap by demanding encryption backdoors. As I’ve demonstrated here, creating encryption backdoors will provide zero defense against “unbreakable” encryption.

In fact, I’ll go so far as to say that should crypto backdoors be deployed, those users who law enforcement most desire the ability to monitor will move to encryption schemes far more difficult to break than those deployed on hosts and in messaging apps today.

This is simply not a battle, nor war, which law enforcement is going to win.

Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.

About The Blogger