From their research paper at https://vuvuzela.io/static/vuvuzela.pdf:

> Vuvuzela can support 1 million users exchanging text messages (up to 240 bytes each) with an end-to-end latency of 37 seconds, achieving a throughput of 68,000 messages/sec.

Unfortunately, 37 seconds, even for a privacy-aware service, seems too slow to deliver instant messages.

While I agree that 37 seconds is slow enough to be noticeable in an intense conversation, I don't think it's a deal breaker.

I don't think all text messaging is equal. If you want a realtime conversation with someone, you probably want to just jump on a call with them anyway.

Furthermore, a system like this, with its extreme level of privacy (and the fact that you, at least at the moment, need a Go toolchain installed locally to even use it), seems to be tailored for a pretty specific kind of audience. That audience is the kind that values, and probably requires for their own personal safety, privacy above all else. 37 seconds of latency seems like a pretty reasonable trade off in that case.

Our latest paper, Karaoke, achieves 6.8 seconds with 2 million active users: https://vuvuzela.io/static/karaoke.pdf

cool! does (or will) the existing Vuvuzela client use Karaoke?

It doesn't yet. I'd like to integrate Karaoke's techniques into the Vuvuzela client in the coming months.

Huh? I think that's plenty enough for most use cases. Sure, sometimes I want text based realtime communications, so I can't have that, but most of the time it's just semi-realtime where this would be fine. But it has to scale to that point first I guess, and maybe things would already have been refined until then.

Personally, I found the research section more enlightening. It lists two papers which talk about their approach:

https://vuvuzela.io/research

Thanks. I just added our latest paper to the list.

Cool, but having to give data to Google to create an account is a major detractor.

Sorry about that. I need some way to prevent someone from quickly registering many email addresses. Do you have any other ideas?

What Gmail did when they started up was to give each early user a small number of invites to hand out to others. That way someone could quickly register, say, five email addresses, but only at the cost of being able to invite five of their friends.

I don't beyond browser fingerprint+ip throttling which may be a step in the wrong direction. Does spark the idea to create a LibreCaptcha.

Registering a large number of rogue identities to exhaust the bandwidth seems to be one of the most practical attacks.

How do you consider that in the threat model of the research paper?

I love it. Gonna try and get some of my friends to use this! Plus there's something unabiguously cool about chatting through the terminal... hacker aesthetic or something like that.

How would you say your privacy + tech measure up against Signal and WhisperSystems? I love those folks and what they build and have been using Signal primarily for texting for a while now.

I agree, I wish Signal could work in my terminal somehow in a way that's more secure than their "Desktop" application. They were storing the decryption keys in plain text in a SQLite database iirc. I understand why they have to store it, but it's just bad if it's plaintext.

There signal-cli [1] which works pretty nicely. Uses SMS for initial signup.

[1] https://github.com/AsamK/signal-cli

What's your attacker model here? On which operating system can the filesystem be compromised, but your application remains unaffected?

Any unencrypted file system can have the conversations in plain text extracted, without having to boot the OS or open the application to decrypt the contents.

jesus christ, i didnt know that....

Yeah, it's cause of the way their crypto works, you encrypt the next message with the hash of the previous or something of the sort. Somebody stored it in plaintext for the desktop version, and I believe it's a SQLite DB so it was easy to discover... It sucks, I wish they had at least encrypted it with a pin at the minimum or something? Maybe Yubikey might make sense for Signalin the desktop not sure.

Also the messages are stored in plaintext:

https://github.com/signalapp/Signal-Desktop/issues/1017

They say it's a non-fix cause you can use full disk encryption, and honestly that's what I do anyway, so I'm not as bothered.

Pardon my ignorance, but is a technology like this anything more than research? Ie, lets pretend there is a market for this (ie, that people actually cared about security), could this be used?

I ask because the 2M (concurrent?) users would be a very small limit in a hypothetical whatsapp/telegram/etc replacement.

So my question is not a critique, but an honest question. I imagine either this is purely research, or that 2M limitation is intended to be setup for communities, where you'll have many 2M instances running. Though, many 2M instances running seems prone to isolating one group of individuals.

Thoughts?

Our followup Karaoke system [1] can support more users by adding more servers, but we still have more work to do to support billions of users. Regardless, I think it's worth deploying these research prototypes to get a sense of what problems matter to users.

[1] https://vuvuzela.io/static/karaoke.pdf

> Vuvuzela is the first system that provides strong metadata privacy while scaling to millions of users. Previous systems that hide metadata using Tor (such as Pond) are prone to traffic analysis attacks.

Pardon my ignorance here, so how is something like my IP hidden from the centralized server? I would assume "strong metadata privacy" would include the most obvious metadata, IP, and keep it from the server like Tor which they compare against.

> Vuvuzela is secure against adversaries that observe and tamper with all network traffic, and that control all nodes except for one server. Vuvuzela’s key insight is to minimize the number of variables observable by an attacker, and to use differential privacy techniques to add noise to all observable variables in a way that provably hides information about which users are communicating.

Someone watching all traffic will know that you're using Vuvuzela, but won't be able to figure out who you're communicating with. In Tor, generally if someone can see all traffic they can rapidly trace communication links-- it's encrypted, but the fact that you send packets and induce a chain of a few other packets to the target is a dead giveaway.

I understand the traffic analysis part. I'm talking about individual MITM (e.g. an ISP) or tracking DNS operators. Can my ISP tell the endpoint I'm connecting to? With Tor, my source and destination are anonymized and that provides a level of metadata privacy (strength is debatable of course). I'm wondering if Vuvuzela, whilst comparing to Tor, offers less metadata privacy on this point.

Noise to thwart traffic analysis is wholly unrelated to endpoint obfuscation.

Anyone else receive an error when attempting to register?

`Failed to generate new Alpenhorn client: fetching latest dialing config: config expired on <timestamp>`

Sorry! We signed and uploaded new configs, so it should be working now.

Group chats?

Not possible yet, but I have some ideas.