Life with Crypto Backdoors: Stingrays, Government Surveillance and Crime

Playing out today is a debate about the control of future of technology. After revelations of massive government surveillance programs, new applications deploy strong encryption, touting privacy as a key feature. The authorities, afraid they will not be able to access communications, are attempting to mandate weaknesses in these applications to ensure they can gather data when needed. This debate hinges on how such backdoors would be used and whether they can be kept out of the hands of criminals. Pro-backdoor groups often point to real criminal investigations that would be helped by backdoors, however pro-security groups have struggled to point to the concrete harm of a backdoor.

The pro-security groups’ hand wringing is not necessary. There is a backdoored technology that we can easily use as a case study: cell phones. The lack of base-station authentication and availability of weak encryption has a similar effect to some of the weaknesses proposed to newer technology. “IMSI-catchers” use these weaknesses to pretend to be a cell phone base-station (i.e. a “tower”) so that cell phones connect to them instead of the real network. The IMSI-catcher can then do what it likes with a connect phone’s connection before forwarding it to the real network. This includes identifying what individuals are present in a location, recording call times and parties and even call content in some cases.

This interception that law enforcement agencies are currently uses closely mirror man-in-the-middle attacks possible on a text chat network that has it’s end-to-end encryption broken.

So what harm has come from providing law enforcement these powerful tools? The most obvious is that criminals are using the same weaknesses. While there is very weak data on what is being done with this power, there is evidence evidence that hijacking cell phone links is widespread. We should expect that if we weaken email, chat, cloud-backups and other online apps criminals will fined a way to use them too.

Damage can run deeper, however, undermining the justice system itself. During criminal prosecutions in the US the use of IMSI-catchers is being hidden from defendants. This hurts defendants’ rights as it limits their legal options. Even scarier, real criminals may have convictions overturned on the basis of the murky tactics used to convict them. Again, we should expect that weakened cryptography will lead to dodgy convictions and procedural acquittals of the guilty.

We have seen a second legal run-around result from stingrays: law enforcement agencies have been using pen-registers as authorization to avoid the more stringent requirements of a warrant, which judges say should be required. This has resulted in several incidents that indicate bulk surveillance of protests, which could never get a warrant. Clearly we should expect that if our lives are easier to be watched, then they will be watched more.

Criminal, procedural and civil rights issues like we have seen as a result of weak security in cell phone technology is a taste of the future – if we allow backdoors in technology. Only with ubiquitous encryption can we preserve the integrity of justice, protecting the public from criminals and unconstitutional government surveillance alike.

Make bash show the return code

When using a command line interface, I like to see all the output a program makes. The standard out and error are already dumped to my console, but there is one piece of information usually hidden from the user: the return code.

Add the following to your .bashrc to get a nice notification if a program returns a non-zero code:

export PROMPT_COMMAND='ret=$?; if [ $ret -ne 0 ] ; then echo -e "returned \033[01;31m$ret\033[00;00m"; fi'

It looks like this:

user@host$ false
returned 1

NSA Puzzle

The NSA recently declassified their Cryptolog internal magazine. I would like to share one gem from Cryptolog XIV, No. 1 – 1st Issue 1987:


The occurrence of “NSA” as a letter sequence in English words is rather uncommon. Some of the rare examples are show below. Fill in the blanks to reconstruct the “NSA” words defined.

Crazy _ n s a _ _
“Land of Opportunity” _ _ _ _ n s a _
Lacking sodium chloride _ n s a _ _ _ _
Pay for damages _ _ _ _ _ n s a _ _
Miniature tree _ _ n s a _
Unable to be satisfied _ n s a _ _ _ _ _ _
Across the ocean _ _ _ n s a _ _ _ _ _ _ _
Middle eastern inn _ _ _ _ _ _ n s a _ _
Unhealthful (as a climate) _ n s a _ _ _ _ _ _ _ _
Not spoken _ n s a _ _
Search thoroughly _ _ n s a _ _
Deny or contradict _ _ _ n s a _
Not paid regularly _ n s a _ _ _ _ _ _
Relationship by descent from a common ancestor _ _ n s a _ _ _ _ _ _ _ _
Unclean _ n s a _ _ _ _ _ _
Result of a bank visit _ _ _ n s a _ _ _ _ _
Disagreeable or disgusting _ n s a _ _ _ _
Type of roof _ _ n s a _ _
Sail on a square-rigged vessel _ _ _ n s a _ _
Able to combine with other substances _ n s a _ _ _ _ _ _ _

1st Issue 1987 * CRYPTOLOG * page 29

How Domains Became Backwards

Internet URLs, file system paths and IP addresses usually get more specific as you move towards the right hand side. This is a clearly a byproduct of the left-to-right language of the designers of these systems. So why is it that this website is and not net.newgas.david?

The familiar hierarchical naming is part of the “Domain Name System” created in the early 80’s by early internet engineers. They already had a internet naming system with cryptic, non hierarchical names like BBN-TENEXD and MIT-Multics. This was basically maintained in one giant text file managed by one organisation.

Faced with a network growing at ever increasing pace this system was becoming a nightmare to maintain. A naming system that followed administrative hierarchies seemed obvious, and was spelt out in RFC 822.

At this stage the right-to-left notation was already settled so to answer our question we must go further back to RFC 805, with the unhelpful title “Computer Mail Meeting Notes”. Here they discuss exactly how to add the extra hierarchical info.

One of their biggest concerns was email addresses.  These were already of the form user@host and they wanted something that extended this naturally. Here were some options they may have thought of:


It’s fairly easy to see why they picked Cerf@ISI.ARPA – the information consistently gets less specific as you go along. The other options are more jumbled. Quoting the RFC makes me sound foolish for even thinking the addresses are backwards:

… the [email address] would read (left to right) from the most specific to the most general.

So there you have it – domains have the most specific part on the left hand side to make email addresses look good!