On Wed, Nov 13, 2019 at 5:16 PM Anonymous wrote:
> It is argued that as long as at least one of the servers aren't compromised, the protocol should work just
> fine. However, can't a compromised server simply pass the traffic intended to go to an honest server to a
> malicious one and that way completely circumvent the shuffling applied by the "at least one uncompromised"
> server?

This wouldn't work because of the onion encryption. The client has already encrypted its message with the
public keys of the three well-known servers on the chain, so a compromised server cannot route messages
through a fourth server to "work around" the honest one. That fourth server would lack the private key to
decrypt the honest server's onion layer.

Malte 

 On Wed, Nov 13, 2019 at 8:31 PM Anonymous wrote:
> I am a bit confused about the "synchronous round" concept. I get that each round has a new set of dead
> drops, and each client to declare what dead drop to access, but I am not sure whether multiple users can
> declare the same dead drop to use ( I think no) ? Or only one user can declare one dead drop?

Users who wish to communicate through the same sequence of dead drops use the dialing protocol to agree on a
shared secret that they use to seed a random number generator that generates the 128-bit dead drop IDs to use.
Because they use the same seed, they will get the same IDs even without communicating further.  Unrelated
users (who aren't in a chat) are unlikely to ever choose the same dead drop, as 128-bit random IDs are such a
sparse space that the likelihood of generating the same number is vanishingly small.

Malte 

 On Wed, Nov 13, 2019 at 10:27 PM Anonymous wrote:
> vuvuzela shuffles the request to unlink the users from requests, alternatively, will adding a random noise
> to the latency by holding the request for a while at an honest server have the same effect as shuffling the
> request?

I believe this would work (provided you also add random delays on the return path), but the wait would add
idle time that increases the end-to-end message latency for everyone. But if you sent other messages during
the randomly generated wait time, then you might as well shuffle all the messages to begin with.

Malte 

 On Wed, Nov 13, 2019 at 10:35 PM Anonymous wrote:
> I am wondering whether the constant-bandwidth mechanism will affect the scalability of the system. For the
> cover traffic, it stats that a constant number of cover traffic is needed. But for the constant-bandwidth
> mechanism, when users are not sending messages, Vuvuzela also requires to send additional messages. Will
> this overhead affect the system's overall scalability?

It's a constant baseline cost to pay for running Vuvuzela at all, but since the cover traffic does not scale
with the number of active users, it doesn't affect scalability. The scalability problem is that more users
require longer rounds, which increases end-to-end delay; Vuvzela's fixed round length requires a one-off
configuration of a maximum number of users who can use the system.

Malte  

 On Wed, Nov 13, 2019 at 10:51 PM Anonymous wrote:
> All the conversations mentioned in the paper are between two clients. Would the system work for a group
> chat? The paper has a small section on how multiple concurrent conversations can be supported, which could
> be used for group chat. But can the messages be broadcasted to a group instead of just one client? Multiple
> users can agree on a dead drop to use, and the server will broadcast back the messages to every user (except
> the sender), and all users still need to send a random message to a random dead drop even if they are not
> active, and noises and encryptions still get applied to every message. Or does privacy guarantee becomes
> much more difficult with multiple clients?

The protocol requires swapping the message in the dead drop with the one carried by the access. This makes
group conversations via a single dead drop difficult, as the message is no longer in the dead drop after the
first access.

Malte 

 On Wed, Nov 13, 2019 at 10:58 PM Anonymous wrote:
> Considering the example given in figure 4 and assume there are only Alice Bob and Charlie in Vuvuzela chain,
> isn't it quite simple for the attacker to look at the underlying TCP packet to figure out which IPs are
> connected to the Vuvuzela that he/she controls and subsequently know who are communicating by investigating
> the IP addresses?

An attacker who compromises the first server indeed finds out the IPs of all people connected to Vuvuzela. But
that information is useless, as the attacker cannot determine which pairs of IPs are actually communicating
(for that, they would have to match dead drop access to IPs, which the mixing by an honest server prevents).
Even if only two people are connected to Vuvuzela, the attacker cannot tell if they're talking to each other,
or to other (disconnected) users, or not at all: the cover traffic and the default empty messages hide the
communication pattern.

Malte 

 On Wed, Nov 13, 2019 at 11:27 PM Anonymous wrote:
> I may have missed it but what is the main source of added latency? 37 seconds seems like a really long time.

> In the example of a million users, I'm thinking it is the processing of a million requests at each server in
> the chain that sort of builds up to 37 seconds. If that is indeed the case, it seems to me that it would be
> possible to load balance it out to maybe 5 separate server chains (each handling 200,000 requests) and the
> privacy guarantees that vuvuzela provides would still hold (+ fault tolerance).  Is this accurate?

Yes, that is indeed the case. It's tricky to maintain security when load-balancing across multiple chains; the
Stadium paper (https://people.csail.mit.edu/dtl/pdf/tyagi-stadium.pdf) looks into one feasible design.

Malte 

 On Thu, Nov 14, 2019 at 1:52 AM Anonymous wrote:
> 1. The paper talks about DoS attacks not revealing any more information unless the users switch to a
> different chat protocol. However, if users disconnect from the system when denied service wouldn't it be
> easy to distinguish between active and idle users -- regardless of if they use another messenger?

Yes; Vuvuzela (as per footnote on page 1 and end of §2.2) assumes that many users are connected even if idle
(matching real-world behavior with Slack etc.).

> 2. I was confused about the conversation and dialling protocols -- can they happen simultaneously with
> different sets of dead drops? Or does everyone have to wait when a `dialling round' is in progress?

I believe that a dialing round can, in principle, happen in parallel with the messaging rounds that precede
it. However, the message round *after* the dialing round (which will use different dead drops for each user,
as the users establish a new shared secret) would have to happen strictly after the dialing round completes.

> 3. Since the dead drop is rerandomized every round -- are they also cleared out every round of previous
> messages? If yes, how exactly would retransmission work if previous messages are erased? If no, wouldn't it
> cause leakage of information?

Yes, they're cleared -- see §3.1 (each round has a new set of dead drops).

> 4. It seems as though when the number of users increase the latency of Vuvuzela would increase but the
> bandwidth per user would remain the same -- is this accurate?

Yes, that's correct (as per end of §8.3 and Figures 9/10).

Malte 

 On Thu, Nov 14, 2019 at 2:15 AM Anonymous wrote:
> If you divide up the servers into 3-4 server groups, so that messages from a clients associated with the
> same server group must only pass through the servers in that group (1/3 w/ 3 servers), can you increase the
> scalability of Vuvuzela without affecting the privacy guarantees?

It's tricky to maintain security when load-balancing across multiple chains, as each chain must have enough
cover traffic to hide who's using it. The Stadium paper
(https://people.csail.mit.edu/dtl/pdf/tyagi-stadium.pdf) looks into one feasible design for scaling Vuvuzela
via multiple chains.

Malte 

 On Thu, Nov 14, 2019 at 1:36 PM Anonymous wrote:
> * I am skeptical that the performance is as claimed. They tested for 5% real-usage, but that wouldn't work
> real-world application since 5% usage would not pay for the $10000/month server. I am wondering what the
> performance would look like when 95% of the users make dial requests.

Note that more than 5% of users can be active in conversations at any time -- this number is merely about the
fraction of users who are initiating a *new* chat session in each round. For that, 5% seems more reasonable.

If there were more than 5% of users dialing in each round, my understanding is that the latency for the
dialing round would go up, meaning that it will take longer for the subsequent messaging round to start. But
rounds after that one would be fast again.

Malte