The code less travelled
Jonni Bidwell had never talked to anyone who programmed BASIC for helicopters. Until he met Eleanor McHugh…
Eleanor McHugh takes us on a journey from a physics degrees to Visual Basic helicopter navigation, to the idea that a right to privacy is a delusional ideal Jonni Bidwell should let go.
on wanting to join the arms race… “This was in the 1980s and there was huge amounts of money in Strategic Defense Initiative-type projects, and really I wanted to build rail guns and gamma ray lasers”
Eleanor McHugh describes herself as a privacy evangelist and freelance reality consultant. Her “accidental career” has seen her working on avionics, satellite comms, broadcast TV and, latterly, digital identity systems. She’s also a speaker at Ruby and Go conferences. We met her at the O’Reilly Software Architecture conference in October 2017 to find out more. Linux Format: You’ve had quite an illustrious career path: trained as a physicist, worked on aircraft systems and are now involved with digital identity management. It’s quite dizzying just thinking about it. Can you tell us a bit more of your story? Eleanor McHugh: It’s a purely accidental career. When I went to university I wanted to go off and build rail guns. LXF: I can sympathise. EMcH: This was in the 1980s and there was huge amounts of money in Star Wars type projects [see Strategic Defense Initiative], and really I wanted to build rail guns and gamma ray lasers. Unfortunately, I spent too much time at uni hacking on computers and not enough time paying attention to electronics lectures. I disastrously ruined my degree the first time and had to resit it. At that stage, the only thing that I was qualified to do as a mainstream job was advise on the safety and control systems of nuclear reactors, which isn’t a particularly broad market. LXF: Hey now, if it’s good enough for Homer Simpson… EMcH: Yes, and I must admit I’ve watched him over the years and thought to myself, “If only”. But I don’t think I could be trusted with that responsibility in the long term. So after a couple of years of doing the kind of stuff you do when you finish uni and haven’t got anything to do, I figured that I’d spent all of my life playing around with computers anyway – I’ve been coding since I was about 11 – so I thought, “Why don’t I do that? How difficult can it be to earn a living as a programmer? They’d be paying me to do what I love.”
Except that’s not really how it turned out. I drifted through an MSc, and then by accident a friend was working on aircraft control systems. He invited me to do a very short project for three months that would’ve paid for my MSc. I needed a dissertation topic and I needed the money, and he insisted it would only be three months. So two and a half years later when I finally got out of that particular field I was a burnt-out wreck. Yet I had created something that I’m still incredibly proud of, but which shouldn’t exist: a cockpit navigation system written in Visual Basic 5. LXF: I am at once impressed and terrified. EMcH: It was certified for use in emergency service helicopters in Derbyshire, Durham and Strathclyde. Real lives being saved by this damned thing I made. As I say, I emerged from that a burnt-out wreck. I think a lot of people’s first programming job was like this: working stupid hours, not sure what you should say no to.
So I drifted through a couple of projects with a team doing satellite communications, then over into real-time broadcast control networks for television. I got burnt out on that, too: four years of dealing with a client who was very, er, special left me not wanting to deal with people any more. I think I went for about seven months without speaking to anyone.
Then I was sucked into this weird project by a friend. He was the CTO of an ISP based up in Camden – it was the only certified ISP that could do DNS registration. Because he was my best friend’s fiancé she bullied me into going to a project for him because he needed some work doing and couldn’t really afford it and I would do it on the cheap. Friends… they don’t care about your mortgage. He jumped ship from there because he got this brilliant offer to CTO another project with another company. I was left behind with this thing, they just sold the company, and the people that bought it didn’t want to build it. I didn’t really want to build it either. But they did want to keep paying me for three months so that they at least had the option to build it.
In that time he put together this team to work on something called dotTel. The idea was that ICANN wanted to prove DNS that could be used for more than just looking up machines. So it was really the start of the whole move toward novelty domains. I think at the time they were called sponsored gTLDs. And it was a totally mad project, because what they really wanted to do was take a global address book system, which they wanted to implement as an
identity system. They’d been trying to do it with LDAP, and unfortunately LDAP doesn’t scale to the world.
So they just ported the design into DNS, they brought in two very highly regarded DNS experts who were respected IETF members, who also hated each other and couldn’t work together. If one said “black” the other would say, “I’d go for white, but white isn’t far enough away from black.”
Up until then I had mostly specialised in large projects, but as the only developer on them. Rapid development to see what was possible, and then putting that into production if it worked and when it was ready. So they wanted me to build prototypes of all these systems that were going to sit behind it and do all the provision of DNS and everything. It was my first privacy project, although we didn’t really think of it as a privacy project, and it’s where I first worked with my current business partner. LXF: What did you work on? EMcH: Some really weird stuff. The trouble with coming from a physics background is that you’re always looking to figure stuff out. And not in an engineering sense of, “Let’s get it to where it works.” There’s always this lurking desire to find some grand theory behind things, ideally one that will cut down your work in the future.
I worked for this company for nine months, then it sacked me, then it paid me for six months as a consultant to finish building the prototypes, but I wasn’t allowed in the building. Unfortunately, the original CTO died and the new guy wanted a clean sweep, a whole new approach and a whole new team. He was happy to throw money at a large organisation to build all their software, but nobody could build it because nobody could understand the documentation. Nobody except me.
So I ended up prototyping this thing in Ruby, which by and of itself was weird, but hey, at least it’s not Visual Basic. My business partner was working on this project because he’s a cryptographer. So we started trying to solve problems around all these people using this public data store, but at the same time keeping personal data private to just them and people they wanted to “friend”. This was around 2005-6, just when Facebook was becoming a thing.
So everyone was obsessed with trying to solve this friending problem, and you really didn’t want to put friending in DNS, because that’s the last place you wanted to put your friends’ data. I will admit that I wasn’t necessarily in the best state of mind when I got out of that project, so I went off and did some stuff that was properly dull by comparison – a few bits of consultancy and some public speaking about real-time software. LXF: But you’re back involved with privacy stuff now? EMcH: Yes, and again it was more or less by accident. When we parted ways my business partner and I decided that we wanted to build a decent network distributed operating system. It’s a problem we both had an interest in, but also a problem that’s a bit like, “How long is an endless piece of string?” It’ll never get done. But it enabled us to continue doing private research together outside the scope of our commercial work.
In 2012 I was approached by a marketing company to do some work for it. It was supposed to do with global scaling stuff, because it provided back-end systems for large multinational companies’ marketing operations. And lo and behold, within about three weeks of starting with this firm, up pops a project for a council that required a deep knowledge of cryptography in order to build a data store.
So I did that, then up pops this requirement from a tier one bank: ”We’ve got this global marketing competition system, we need to do single sign on (SSO).” So the next thing I know I’m writing this SSO identity system for global deployment on this one awful Rackspace box (hosting two VMs) that was never up to the job.
That got me back into the crypto stuff, and off the back of it took our research in different directions. And we thought maybe
we could do this global identity system properly. We knew what went wrong with it the first time, we’ve seen an example of how we can do anonymous token exchange for this SSO. My business partner’s background involves a lot of public key infrastructure (PKI) so he’s seen how PKI doesn’t really work for smartcards, identity cards and all these sorts of things. So we had a whole list of stuff that we knew not to do, so we thought, “If we just don’t do those things, then surely we’ll have stepped forward,” at least compared to what everyone else was thinking.
We spent a couple of years working with a client on a particular project that found ourselves involved with privacy in way that most people working in the area just aren’t. Rather than trying the angles that people have traditionally used to solve this problem, we opted for building from the ground up using anonymity.
So for the past three years I’ve been roaming the world blathering to people about privacy and showing off practical chunks of code for doing various tricks, alongside talking about programming languages that I’m interested in, which happen to be Ruby and Go. It’s a weird sort of a career, probably not by any stretch of the imagination what most people would even call a career.
I mean, I refer to myself as a freelance reality consultant. I’m the ultimate dilettante in IT: I drift from one project I’m interested in to another. And it just so happens that there’s been this common thread – doing a decent scalable identity network – that I can now look back and say has tied this work together over the past ten or more years. We still aren’t there yet. The trouble is you spend two and a half years designing something, but then you also spend that same amount of time figuring out all the attacks on it. LXF: It seems like at least the ideas behind blockchain technology have some use, but that perhaps the technology isn’t developed enough, or maybe the problems it solves don’t exist yet? Even now (nearly one year after this interview took place) it’s hard to see beyond the hype. We keep hearing about how blockchain is going to help supply lines and authentication dilemmas and all sorts of other things, but all that seems far away at this stage. EMcH: All those claims lead to some quite choppy waters. I’ve given programming talks at a conference here in London for the past three or four years. The way conference booking works is for the first couple of years you have to battle your way in and come up with the best possible proposal. Then at some point they give up and decide that they just like having you around, especially if you’re a bit loony.
So I’ve reached that point with this particular conference, because they asked me to talk about blockchain. I thought, “I know nothing about blockchain.” I mean, I’ve avoided it for years. So I ended up putting together a talk, and by the time I’d finished it I thought, “What the heck is everyone making all this fuss over?” I understand that [Satoshi Nakamoto’s] paper was revolutionary when it came out, because at that point nobody was talking about proofs in audit trails. But the underlying technology is very simple.
The trouble is the underlying technology relies on crypto that’s too expensive to run in very small devices. So rather than trying to solve the problem of how we can get proof from these small devices, without having that heavy cryptographic stack, people are instead trying to find ways of shoving that crypto into the small devices.
Eventually, all the small devices will be so powerful that yes, you can do that, but eventually the universe will end too. And I’m not sure which will happen first. The more places you put complex crypto, the more places you’re likely to run into problems. Even this week there was a story on Ars Technica ( http://bit.ly/id-cardflaws 1) about the Estonian ID cards. It turns out Infineon, which really does know what it’s doing, for the past five years has been shipping a library with its smartcard chips that doesn’t produce proper RSA-hardened primes. As a result, someone willing to run a 1,000-node botnet is probably cracking a lot of 1,024-bit keys per day.
I show people how to do stuff with standard cryptographic algorithms, because if they’re broken you can then take the principles and use them with the next algorithm that comes along and replaces them. Good cryptography and good security aren’t necessarily about strong algorithms. They’re about good architecture for what you do with the data. We mustn’t let the data stand still for very long and when it does stand still, we must make as little as possible see it.
Those are principles that a 10 year old can get. In fact, some of the maths that crypto relies on, my nine year old (who was an eight year old up until recently), he was learning about modular arithmetic in class, with little clock diagrams. There’s nothing really complex about the theory behind the low-level stuff.
on being a coding magician… “So for the past three years I’ve been roaming the world blathering to people about privacy and showing off practical chunks of code for doing various tricks”
LXF: It’s funny because when you try and teach that stuff – the Euclidean algorithm and the Chinese Remainder Theorem and such – to undergrads, they really don’t get it. EMcH: No they don’t. They’ve been fairly ruined by then. They’ve already done calculus so they already assume that everything has to be complicated. Last year someone claimed to have come up with a technique for spotting graph isomorphisms, which would revolutionise a lot of prime factorisation stuff and at the same time screw up a lot of current believed-trusted infrastructure.
So all of this stuff is very fragile: we’re beholden to whether or not developers are implementing it well. There’s a very small number of people on the planet who are building crypto libraries and we just have to trust that they know entirely what they’re doing. And we also have to trust that all those people we don’t know about, in organisations that we know have lots of cryptographers, know what they’re doing but don’t know how to break what we don’t want them to. LXF: A lot of people are concerned about GDPR. It seems like it’ll be even more nightmarish for a digital identity service than for many others. How is your business handling that? EMcH: I’m not a GDPR expert. The way our business breaks down is that my business partner does the cryptography and the legal side. He’s spent most of this year tied up with various clients, just getting them to a state where they’ve got all the procedures and the back-end business processes in place so that they’re able to survive GDPR. Which is very difficult, even for businesses that commit to it. I’m on the software architecture side, so I get these things as requirements: “How do we do this, how do we do that?”
So GDPR is a big stick. It’s been deliberately designed as a big stick, and it’s bad legislation I think, because it’s not entirely clear what that stick is for. In my opinion it just as much prevents you from whistle-blowing criminal activity (because that could fall within the boundary of private data) as it does prevents you from leaking personal data. I could be wrong on that: the courts could end up interpreting it very very differently. But that’s what it feels like when I look at the requirements.
It also runs against itself. If I want to build a system that preserves privacy, the last thing I want to be able to do is actually find data for a user, unless that user is doing something to enables me to find it. And yet subject access requests come in as pieces of paper. The right to be forgotten, wonderfully noble though it is, requires that I compromise my crypto system because I have to prove that I’ve forgotten everything. And I can’t prove that without first remembering everything I know.
The crypto side is actually quite simple: one-time pads, fresh key per piece of data, second system that maintains those keys that’s only triggerable with the right keys, a few tokens going around… I say it’s trivial, it’s actually a pain in the arse, but the principles are trivial. I don’t think that’s practical under GDPR. I could be wrong, I haven’t yet had a chance to build something that tries to match all of GDPR’s requirements. Because until people start getting sued no one’s going to put the money up to do that exercise.
I think they should’ve gone for full enforcement the moment it entered law, as opposed to next May. I think there’ll be some high-profile cases and a lot of scared people, because four per cent of global revenue or €20 million (whichever’s larger) is a big deal if you’re not IBM.
As for what counts as personally identifiable data, this now includes characteristic psychological data. Well, that to me sounds like usage patterns. On
the one hand that pushes back against a problem that everybody has: the metadata problem. There are listening stations all over the world that are conducting flow analysis on traffic and they can find out much more from just looking at how the traffic behaves than knowing what’s in it.
The Nazis were brought down by this in the 1940s. It was the Hut 6 stuff that destroyed the Reich, not the Turin decrypts. If that stuff worked then without fast computers to do the data crunching – where as now everyone wants to play with R, everyone wants to do data mining, everyone wants to build convolutional neural networks with deep learning – then we’re creating a situation.
Yes, we should be preventing certain kinds of analysis of usage data, precisely because it’s like fitting a glove to it: you can’t have anonymity. In systems like Bitcoin which is pseudononymous, that’s fine, run a machine-learning algorithm down the blockchain and in a few months I know everything about general usage patterns and interactions. I only need one piece of physical, real-world evidence and suddenly I’ve pulled a whole network of people who are transacting together. We can accept that it’s reasonable for Bitcoin because we accept that people aren’t using it to carry out cash transactions anonymously, don’t we? LXF: Err, I’ve heard some people might do something like that… EMcH: The thing is, for me to know whether or not I’m storing data that’s personally characteristic of behaviour, I’d have to run some algorithms myself and extract that data. That once again puts me in the position of if I want to comply with the law that tells me not to do that, but at the same time I want to prove that I’ve not done it. Ironically, the only way to prove I’ve not done it is to actually do it with some kind of audited anonymous process that I can’t then get the data back out of, only the proofs. But now I’m going to have to run the very attacks I’m supposed to be prevented from being run!
I think the legislators are trying to impose a right of privacy that just doesn’t fundamentally exist. It’s not a human right – it can’t be because it’s impossible to enforce. It’s as nonsensical as saying, “Everyone has a right to a rocket ship”. Fine. Countries that have privacy laws – Germany and France, for example – it leads to all kinds of weirdness. I think fundamentally, certainly in our jurisdiction and other common law jurisdictions, it runs so counter to the idea that if a criminal offence occurs, then you’re allowed to pull all this data out, everything you can get. Courts are entitled to look at evidence.
And that’s another part of what we spend a lot of our time trying to figure out. How can you balance that? Everyone else in the industry takes the position, “Well, the courts mustn’t look at this stuff.” That’s fine until you’re the victim of fraud, or violent crime, then come and tell me courts aren’t allowed to look at that CCTV footage. Until you’re a victim of crime or know people who are the victims of crime, you don’t realise that if you go the absolute crypto route, then you’re building a prison for all the people who are law-abiding, in which all the people who aren’t law-abiding can do whatever they like.
I think the legislators that put GDPR together are coming from that same mindset that a lot of people in the anarchocrypto community do. That government and courts themselves are somehow the problem. Whereas, if there’s one thing that seems to work okay, it’s the courts. Maybe not the police, maybe not the government, maybe not anything else, but the courts actually do what they say they’re going to do. They do ‘Justice’, and sometimes they get justice wrong. We know that, but at least they’re making an honest attempt with clearly laid-out laws. I think some of the wider implications of GDPR are going to be difficult to enforce for the courts.
on the reality of privacy “I think the legislators are trying to impose a right of privacy that just doesn’t fundamentally exist. It’s not a human right – it can’t be because it’s impossible to enforce”
Eleanor McHugh takes Jonni through the ups and downs of her eventful working life.
Eleanor is a joint director at Innovative Identity Solutions.
Good cryptography and good security aren’t necessarily about strong algorithms, believes Eleanor.
Eleanor doesn’t approve with how GDPR has been implemented.
Golang recently rebranded, but the original gopher mascot is still very much a part of the community.