Vuvuzela Messenger: „If there is an arms race, I think we’ll lose if we don’t focus on usability“

Secure messaging systems are vulnerable to generic traffic analysis attacks. In a time of „Five Eyes“ network monitoring almost everywhere, researchers are looking for solutions. „Vuvuzela“ tries to avoid the possibility of a third party analyzing the metadata of its users.

We spoke to David Lazar, who is one of the four inventors of the Vuvuzela system. They designed and analyzed the protocol and proved that it meets their definition of security. David also wrote the code that is in the github repository.

There is also a German version of this interview available.

The Idea

In Vuvuzela, a lot of noise is added to block surveillance opponents like the „Five Eyes“ intelligence agencies from getting their hands on the users’ metadata. Encryption alone cannot hide the amount of idle users and of communicating users, therefore the noise thwarts sophisticated attackers who try to analyze metadata to see who is talking to whom. Vuvuzela servers make the noise that disrupts the analyzer’s metadata exploitation and protect against traffic analysis.

There are some secure messaging systems with metadata protection already. Pond is an example of a system that tries to hide metadata. Dissent (pdf) is another system, published a few years ago.

The Vuvuzela concept paper (pdf) was released in October 2015 at the 25th ACM Symposium on Operating Systems Principles by Jelle van den Hooff, David Lazar, Matei Zaharia and Nickolai Zeldovich.

Vuvuzela consists of a single chain of servers to which clients connect to communicate. We assume that the chain of servers, along with each server’s public key, is known to clients ahead of time; all clients use the same chain. Clients always connect to the first server in the chain, which in turn connects to the second server, and so on.
Vuvuzela clients participate in two protocols. The first protocol, called the conversation protocol, allows a pair of users to exchange messages, assuming that they both decided to communicate with one another. The second protocol, called dialing, allows one user to request a conversation with another.

Interview with David Lazar

Different from other approaches to protect metadata, for example the Tor project, you use techniques to add noise against an attacker who observes the network to collect metadata. Why did you choose this approach?

We designed the system by trying to efficiently encrypt as much metadata as possible. However, there is some metadata that we can’t encrypt efficiently. We add noise to metadata that isn’t encrypted so that its meaning is obfuscated to the adversary.

Efficiency was one of our goals from the start. We found that adding noise gives pretty good efficiency and pretty good security.

For that noise, how much server bandwidth for the dialing protocol would a user need right now, say if I beta-tested it?

Each user needs about 12 KB/s of bandwidth to run the Vuvuzela client. 12 KB/s is high if you want to run a Vuvuzela client on your phone. We’re thinking about ways to reduce client bandwidth costs.

Vuvuzela’s two protocols communicate through „dead drops“ where one client deposits a message, and another client picks it up. Will there be a CDN (Content Delivery Network) in the future for distribution of the dialing „dead drops“?

Yeah. Our current plan is to use BitTorrent to distribute the dialing dead drops, but we haven’t implemented that yet.

Can you already say when the implementation will start?

There’s two things that are keeping us from deploying Vuvuzela. First is the lack of a PKI [Public Key Infrastructure] and second is the lack of a way to distribute the dialing dead drops. I’ve started to work on the PKI, and I expect we’ll integrate BitTorrent shortly after we have a PKI.

There’s also some hope that we can design a more efficient dialing protocol, so that we don’t need a CDN or BitTorrent for dialing.

But for beta-testing I could use pki.conf for test purposes?

Yeah. You’d have to exchange keys with your friends through some other channel.

From the users’ perspective: When starting a conversation, for each communication the user needs to start the dialing protocol, right?

Yeah. If Alice wants to talk to Bob, she types /talk bob followed by /dial bob, which alerts Bob’s client that Alice wants to talk. If Bob wants to talk, he types /talk alice, and now Alice and Bob are in a conversation.

Alice’s public key will be transferred to Bob, but a shared secret is formed, so the first dial-up to a communication partner has to start all over again when the next conversation between them begins?

Right. However, currently Alice and Bob need to have each others long-term key in pki.conf to ensure that they’re talking to the right person. In the future, a better PKI will make this process more friendly.

Will it be as user-friendly as it is in OTR or GnuPG?

Yeah. Ideally it’d be even more user-friendly. :)

You also did some research on user-friendly systems. Is it correct that you would consider the usability important?

I think usability is very important. If the system isn’t user-friendly, then no one will use it and that’s bad for security.

If you focus that much on usability, do you think it could be an advantage for Vuvuzela to find a lot of users because it is not only secure but usable, too?

I think it’d be great if users are drawn to Vuvuzela for its usability, not just its security. But we’re a ways from that.

But it mostly comes with compromises if the user can – willingly or without understanding it – undermine the security. How will you cope with that problem?

It’s a hard problem. One approach is to try and provide pretty good security by default (with no user effort), but offer the possibility of ironclad security with some user effort (for example, by allowing users to verify their friends’ keys).
I think Signal takes this approach.

In your paper you describe the idea to use users as „noise“, once there are a lot of them. How much could it reduce bandwidth use?

That’s not clear. Perhaps we could get rid of most of the noise when there are a lot of users, but at that point, the bandwidth cost is dominated by user (non-noise) messages anyway.

When will a user client be ready, and when the wide-use deployment?

I’d like to deploy it in the first half of this year.

There are now a lot of new crypto messengers, and counting since the revelations of Edward Snowden. Is the creation of „Vuvuzela“, especially because it is also protecting metadata, a reaction to Snowden’s revelations?

Snowden’s revelations motivated the work, but we also find the problem of hiding metadata interesting and challenging.

Would you go as far as it to say, there is a kind of arms race between the NSA complex (with „Five Eyes“) collecting all the metadata and researchers and activists to build systems like yours?

If there is an arms race, I think we’ll lose if we don’t focus on things like usability.

Well, I have to finally ask because everyone wants to know it: Why did you pick that Vuvuzela-name where everybody thinks of that screaming noise?

The system adds a lot of noise, so we thought Vuvuzela was an appropriate name. :)

David, thank you for answering the questions!

If you are willing to run a Vuvuzela server in Germany or elsewhere in Europe, please contact constanze(at)netzpolitik.org.

Transcription and Translation: Constanze and Jakob.