1. ---On the ‘Vuvuzela’ Scheme
Private Messaging
---On the ‘Vuvuzela’ Scheme

2. Our model: Vuvuzela
A protocol that hides metadata, i.e. Information other than the message itself,
such as the sender and receiver, the number and lengths of messages, etc.
From： Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis.
Jelle van den Hooff, David Lazar, Matei Zaharia, and Nickolai Zeldovich
MIT CSAIL
Use a chain of servers, and in each round, every user sends its message
through the chain.
Assumption: at least one server not controlled by the adversary (i.e. n-1 servers are potentially ‘bad’)
Security notion: we suppose that the adversary is ‘curious’, must follow the protocol.

3. Our model: Vuvuzela On the client’s side: onion wrapping:
first message is a secret sharing, en+1
for each server, use a (randomized) key pair of server i to encrypt:
en = Enc(ski, pkserveri, en+1), and include pki
On the server’s side:
1, decryption and re-encryption by the onion rule.
2, shuffle according to a random permutation π. On the last server, exchange messages.
3, cover traffic: to hide the ‘tag’ for each exchange, generate ‘fake’ messages on each server.
When there is one good server, the message can be shuffled and added with cover traffic with the right distribution---Deniability.

4. A first modification
On the quantity of traffic of the system: If for all clients, can wait for some rounds. Suppose that it sends message every k rounds: then the traffic would also be reduced by 1/k. We can randomize it according to a particular distribution i.e. for uniform distribution with parametre k, a client wait with probability 1/k Constant factor(1/k) improvement on traffic, with k waiting time increase(no changes on the assumption). If randomization is used, then on an average traffic would be the expectation of that distribution, i.e. also constant factor.

5. Vuvuzela & Onion Routing
Consider a combination of Vuvuzela and OR View a Vuvuzela as a ‘unit’, and connect by a network. For message exchanges within a Vuvuzela, it is the same. Inter-unit changes: at the end of the chain, the server re-wrap it using OR protocol, and send it out. The units it passed is onion-wrapped by the sending client. Between each two units, they must add cover traffic to cover actual inter-unit transmissions. OR V2 Vk

6. Vuvuzela & Onion Routing
The clients are mapped to units according to locality rule(i.e. IP prefix, etc.), so expected number of inter-unit traffic is relatively small
The clients can choose random units: according to shared secret with the one contacting. (for example, H(s, r, A), s-shared secret, r-random nonce, e.g. round number, A-Alice’s ID), then we need no cover traffic. (On the other hand no locality property; also in one round one can only contact with one another)
Assumption: if there are k units, then we assume k out of n are good.
Complexity: no waiting time. Cover traffic between units: O(k2), can choose k=sqrt(n)

7. Problem and future work: the dialing protocol
To initiate a conversation with another user: dialing Since the receiver does not know the tag ( called dead drops) we have to use a large number of tags instead of a particular tag. As far as we can see, we use the same mechanism as vuvuzela, with all units sharing the same set of dead drops for invitations. The problem is downloading them: they could be very large!

8. Thank You!