1. GZ06: Vuvuzela Scalable Private Messaging Resistant to Traffic Analysis Xizhe Jiang & Yue Wang 18th March

2. Motivation ●Users would like their communications over internet to private. ●Encryption can hide the content but can not hide the details. Adversaries could still learn a lot from the meta data.(e.g. who they are communicating, at what times they communicate, if you talk to a criminal, you might be one) ●“If you have enough metadata you don’t really need the content” -- NSA General Goal: ●Provide point to point communications between the users against the strong adversary. ●Not able to distinguish between the a scenario where two users are communicating or not (Differential privacy). 2

3. Related Works Dissent and Riposte: ●Strong provable privacy guarantees. ●But need to broadcast the messages to all users, or use computationally expensive cryptographic constructions. Tor: ●Provide little protection against powerful adversaries (observe and Temper). ●Need a large number of users to provide any degree of privacy, which is expensive and only limited of protection. 3

4. Tor ●Sender knows the public keys of all relays by initially encrypting the message(including ip) with: and send to the first relay. ●The message will be decrypted layer by layer like an onion on the way to the receiver. ●Each relay only knows the previous relay’s ip. 4

5. Challenges of Tor ●Boundary traffic may not be encrypted. (e.g. through HTTP) ●A research team from ESIEA announced that they are able to compromise Tor by control one third of the nodes, requiring creating a map of the nodes. ●Traffic-analysis attack ●Bad Apple Attack... 5

6. Contributions of Vuvuzela ●They claim: the first private message systemthat hides metadata from powerful adversaries for millions of users. ●Vuvuzela scales linearly ●Differential privacy for millions of messages per user (will not expose privacy). ●37s latency for 1 million users ●60000 messages/per second throughput ●Private text-based message... 6

7. Differential Privacy ●An quick quiz about gender…differential attack ●Neither of these expose your privacy if asked separately. However, if we could combine the answers, then...lol ●Fundamental information recovery tells us Overly accurate estimates of too many statistics is blatantly non-private…Plenary presentation. ●For any observation O that the adversary might make of the system, the probability of observing O should be similar regardless of Alice’s communication pattern. The formula is as below: 7

8. Basic Privacy Goal Malicious guy should not tell who are talking... 8

9. Threat Model ●All servers but one server could be compromised ●Adversary is active and very powerful (can knock user offline, tamper with messages etc.) ●All users may be malicious ●All users know the public keys of the servers and the public keys of the of all the users who they want to communicate with. 9

10. Vuvuzela Conversation: Talk on dead drops 10

11. Conversation: Talk on dead drops 11

12. Problem: 12

13. Problem: You will find the last dead drop is different which only has one access. If you suspect Charlie, just kill his client and see what happens 13

14. Vuvuzela Solutions ●Introduce a chain of Vuvuzela servers, encrypt the communications among them by using Mix Network design when forwarding messages in the chain of servers. ●Shuffle the order of the messages in each Vuvuzela Server, and un-shuffle the order when the messages come back. ●All clients connects to the system have to make fake actions even they are idle. ●Vuvuzela servers have to make noise(Cover Traffic) in the chain, to guarantee the differential privacy on the dead drop side. ●Round based communication 14

15. Vuvuzela Protocols ●Dialing Protocol Initiate conversations between two users. ●Conversation Protocol Exchange messages between two users. 15

16. Vuvuzela Overview 16

17. Assumption ●Keep at least one Vuvuzela Server uncompromised ●All clients could be malicious ●All clients know all Vuvuzela public keys ●Two clients who wish to communicate know each other’s public key ●All honest clients and servers run bug-free implementations. ●Adversaries could be powerful, monitor, block, delay the network. 17

18. Conversation Protocol Algorithm 1 Conversation round: client Alice talks to Bob ： (1). Using Diffie-Hellman, compute a shared secret S n+1 = DH(sk Alice, pk Bob ), r donates round number. Set the communication dead drop ID to be b = H(S n+1,r). Encrypt Alice’s msg using r and S n+1 to get e n+1 = (b,Enc(S n+1,msg)). msg could be empty, then send empty msg. (2). If Alice is not in active conversation, make fake request. msg could be,empty use pk random to compute S n+1 instead of pk Bob. 18

19. Conversation Protocol Algorithm 1 Conversation round: client Alice talks to Bob ： (3). Generate temporary key pair (sk i, pk i Server ) for all Vuvuzela servers. Encrypt the e i in the reverse order of servers in the chain from n to 1, encrypted with DH(sk i,pk i server ) to get e i = (pk i,Enc(s i,e i+1 )). (4) When receive the msg from the server, if it is the msg for Alice, Alice will be able to decrypt it by its shared secrets: DH(sk Alice,pk i server ) and DH(sk Alice, pk Bob ). 19

20. Conversation Protocol Algorithm 2 Conversation round: Server Alice talks to Bob ： (1). Decrypt the request received by its share secret DH(sk i server,pk i ) (2). Generate cover traffic, add fake requests. (3). Shuffle the request and send them to the next server, when the msg comes back, un-shuffle the responses in the reverse order. (4). Encrypt the msg by Enc(s i,e ’ i+1 ) and return the msg. 20

21. Encryption and Decryption Overview 21

22. Dialing Protocol 22 ●Send and Receiver agree on the same invitation dead drop by receiver’s public key; ●Receiver gets Sender info by direct download invitations; ●Start conversation protocol;

23. Dialing Protocol VS Adversary 1.Which user participated in the protocol each round? -- Fake invitation 2.What dead drop does the sender send to? --Mixnet approach (onion wrap) 3.How many invitation in a given dead drop? -- Cover traffic 23

24. Observable Variables (ε, δ)-differential privacy set of users connected to the systems # of dead drops accessed once # of dead drops accessed twice Adding Cover Noise by Server Single Noise & Double Noise 1.No server compromised; 2.One server compromised; a.server 1 or 2 b.server 3 3.Two server compromised; a.server 1 & 3 b.server 2 & 3 (subsequent) 24

25. Vuvuzela’s Approach to Noise and Privacy Level 25, where s x denotes the action of Alice is talking to Bob, y denotes there is no conversation between Alice and Bob. Suppose x => 1 dead drop accessed twice y => 0 dead drop accessed twice Laplacian Noise: Lap(μ, b) μ is the average noise per server b is scale factor depends on ε the lower ε, the more likelihood the two action are viewed the same from wikipedia

26. Noise Generate in Practice Privacy degrades each round (more metadata leak) more noise means more privacy for more message 26 ●As ε closer to 1, we get more privacy ●The more message Alice want to keep private, the greater ε (Within 1M message, we got acceptable privacy) ●μ is independent of # of users ●μ increase linearly with 1/ε [J. van den Hooff, D. Lazar, etc, 2015]

27. Implementation and Evaluation I.Implementation Setup written in Go (2,700 lines), optimised Go’s crypto lib, due to high en/decryption cost; Entry server (not trusted) notify user of round r, multiplex & demultiplex connections; II.Evaluation: Scale and Performance III.Experiment Setup Amazon EC2 VMs, 36 cores Intel CPU, 60 GB Ram, 10 Gbps network bandwidth 3 servers in chain (each to one VM), 5 VMs as simulated users, 1 VM as entry server Each user send one msg each round. μ = 300,000 for conversation protocol, μ = 13,000 for dialing same data center, as network latency has little effect on performance dominated by CPU crypto computation and bandwidth for transferring requests 27

28. Server Performance ●End to end latency and throughput. Throughput: 68,000 messages / second, two million users 28 [J. van den Hooff, D. Lazar, etc, 2015]

29. Server Performance ●End to end latency and throughput. Throughput: 68,000 messages / second, two million users ●Noise independent of # of users ●Performance(latency) is linear in # of users ●With few users, still 20s latency ●With 1 million users, approx. 37s latency 29 Conclusion [J. van den Hooff, D. Lazar, etc, 2015]

30. Conclusion and Limitation ●Solutions ○Mixnet approach to encrypt data as much as possible ○Add noise to achieve differential privacy (hide metadata) ○Formalize the noise needed by given privacy ●Achievement ○Acceptable performance ○Scale linearly with number of users ●Limitation ○PKI ○Bandwidth cost ○DDos ○Forward secrecy for dialing protocol 30

31. Q & A 31