1. Anonymous Communication Luis von Ahn Andrew Bortz Nick Hopper The Aladdin Center Carnegie Mellon University

2. Motivation • Verizon is being forced to reveal the identities of online music traders • I would rather not lose my life savings to the RIAA, but I just can’t seem to stop trading music either. ;-) • I’d like to trade anonymously, so that no one can prove (to a court) what I was doing

3. Other applications • Privacy in e-Commerce • “Whistle blowers” • Guarantees freedom of speech if one can speak without fear of repercussions

4. The Problem • Really two different problems: • Sender anonymity – hiding the true sender (originator) of a message • Receiver anonymity – hiding the intended recipient of a message • Receiver anonymity is easier • More efficient protocols exist • Seems to come “for free” with many sender anonymous protocols

5. An intersection attack • Sender and receiver anonymity are equally important in two-way communications • Consider just sender anonymity • A malicious sender can entrap another by sending a message to just them. If they respond, even though they should have sender anonymity, the malicious node knows who they are • In two-way communications, your anonymity is a function of the intersection of the size of the groups you hide in for both sending and receiving

6. Definitions? What are those? • When we get to formal definitions, there is no universal agreement • To do anything meaningful, we need to have a good understanding of: • What constitutes “anonymity”? • Who is our adversary, and what is he capable of doing?

7. What is anonymity? • Consider full sender anonymity: • Intuitively, an adversary cannot distinguish the sender from the other honest participants • Formally, computational indistinguishability seems reasonable • No polynomial-time adversary can distinguish the true sender of a message with non-negligible probability • But that’s not enough! • A protocol needs to “do” something in the face of an attack - robustness • Other, more restricted ideas about anonymity

8. Who is our adversary? • Many possibilities, but here are some common ones: • Honest-but-curious users • Passive, global eavesdropping (secure channels) • Honest-but-curious group of users • Malicious group of users • Malicious group of users with eavesdropping • Malicious group of users with eavesdropping and the ability to drop packets

9. Solutions - Mixes • In the beginning… we had David Chaum’s Mixes: • A single trusted machine (mix) that would facilitate anonymity • To send a message, send it to the mix and the mix will send it to the recipient • Provides sender anonymity • If the mix broadcasts the message, we get receiver anonymity too

10. Solutions – Mixes (2) • What adversarial models is this secure in? • Not one with eavesdropping – we can tell who is sending a message • Simple solution – make everyone send a “message” to the mix all the time, at the same time • Interesting solution, but finding a “trusted” mix is hard

11. Solutions – Mix-Nets • Let’s have a lot of untrusted mixes • To send a message, choose a path of mixes and send a message to be routed through them • Problems: • Not secure in eavesdropping models • Difficult to prove security in other models as well • Most of all – not robust! (or rather very difficult to make/prove a robust protocol like this)

12. Solutions – Onion Routing • A common extension to Mix-Nets • Encrypt message in layers, one for each hop on the path • When a machine gets a message to be routed, it decrypts it, sees only the address of the next hop and another encrypted message, and forwards it • More secure than Mix-Nets, but suffers from some of the same insecurities

13. Solutions – DC-Nets • Can we even get a good solution? Yes! • DC-Nets: • Also by David Chaum • Secure against the most powerful of adversaries • Even some computationally unbounded ones that were not in the previous list

14. How does a DC-Net work? • It is a multi-party sum protocol: • A bunch of people want to calculate a sum of each of their private values, but don’t want anyone to know what those values are • Each pair of people chooses a random pair of numbers that sums to 0 (random x and –x) • Each person computes the sum of all the secrets they know and their private value, and broadcasts this sum to everyone • When you sum together everyone’s broadcast, all the randomness cancels out, and you are left with the sum of everyone’s private values

15. How does a DC-Net work? (2) • Multi-party sum is secure • Unless the adversary knows all your secrets, your value is hidden by a random number • DC-Nets use this as a shared channel • To transmit, choose your value to be your message. Otherwise, choose 0 • If only one person transmits, everyone gets the message. Otherwise it is garbled

16. DC-Net tricks • Problem: an adversary can transmit all the time, and thus no one else can • Solution: (overview) • DC-Nets use a complicated reservation and trapping system • Nodes anonymously reserve a time slot for the shared channel • If a node transmits out of turn, there is a fixed probability of them being detected

17. Solutions – DC-Nets (2) • Why don’t we use DC-Nets? • Huge complexity by any measure – rounds, messages, bits • Best attacks on robustness allow up to O(n2) attacks before an attacker is kicked off • Why are DC-Nets good? • Proof of concept – it can be done, it may just be really really inefficient

18. New definitions • People have been banging their heads against the wall for a while with this problem – let’s cheat and try an easier one! • Hence, k-anonymity: • Instead of hiding amongst all the honest users, let’s just make sure we are hiding with at least k of them

19. K-Anonymity • Easier, but still very useful: • In the absence of other evidence, you only need 2-anonymity to raise “reasonable doubt” in a US criminal court • 3-anonymity is sufficient for a US civil court • Even 2-anonymity wrecks havoc with data profiling techniques

20. Our contribution • An efficient protocol for k-anonymous communication • We assume a powerful adversary – a group of malicious users with eavesdropping • We catch cheaters with high probability without compromising anonymity

21. Overview • Break the network into groups of size O(k) • Each group (of size M) runs 2M parallel shared channels • To send, choose one of the 2M channels and send a message of the form (destination group id, real message), and send nothing in the other channels • When a group computes a message on one of the shared channels, it sends it to the destination group

22. Security • Anonymity • Each shared channel is implemented with a multi-party sum protocol, so message sending is anonymous • Since an entire group receives the message, message receiving is anonymous too • Intersection attack doesn’t gain anything, so this is secure for two-way

23. Security (2) • Robustness • Adversary can try to hog all the channels, but if more than M of the 2M channels are used, then everyone knows someone cheated • In that case, use a zero-knowledge proof for each participant to prove he used at most 1 of the channels – guaranteed to reveal at least 1 cheater

24. Efficiency • Constant number of rounds = 4 • Very good for latency-bound networks – like the Internet • O(M2) messages per anonymous message sent, O(M3) bits per anonymous bit sent • Still decent since M = O(k) • Alternate strategies to improve our protocol’s best-case complexity to O(M) messages per anonymous message sent • One sacrifices a bit of robustness, the other increases the round complexity by 2

25. Future work • “Stop fooling around and do it!” • Implement one or more of these protocols (either for real or in a simulator) • See how they work, in terms of efficiency • Easier, but not nearly as interesting

26. Future work (2) • “Stop fooling around and solve it!” – a few good possibilities for future work • Build a good formal model for the problem • Define various types of anonymity • Generalize adversaries • Prove interesting/good/powerful results • I.e. there are a bunch of seemingly impossible scenarios for anonymous communication • It would also be good to find an optimal solution, or a good lower bound for one

27. Future work (3) • My current focus: asynchronous protocols • All protocols so far that are secure against an eavesdropping adversary use a synchronous ‘round’ structure – a group of users all do something at the same time • Asynchronous protocols would be more efficient, but are they even possible? • (Likely they are not, but it seems hard to prove)

28. That’s it! Any questions?