Dissent in Numbers: Making Strong Anonymity Scale David Wolinsky 1 , Henry Corrigan-Gibbs 1 , Bryan Ford 1 , and Aaron Johnson 2 1 Yale University, 2 US Naval Research Laboratory
Motivation – Strength in Numbers Meet tonight at 7 PM in the park for pizza and beer! Bob, you’re going be spending some time in the slammer!
Motivation – Strength in Numbers Meet tonight at 7 PM in the park for pizza and beer! All of you going to be spending time in the slammer!!!
Motivation – Strength in Numbers
Motivation – Strength in Numbers Meet tonight at 7 PM in the park for pizza and beer! Ugh, we can’t put them all in Jail… This party is over go home!!!
Making Strong Anonymity Scale? • Challenge – tradeoff between scale and strength in anonymity systems favoring scale • Goals • Strong anonymity (timing analysis resistant) • Scalability (100s to 1,000s of active participants) • Churn tolerant (unannounced member departures) • Accountability Achieved in Dissent!
Organization • Motivation • Existing Approaches • Dissent – Strong, Scalable Anonymity • Computational efficiency • Communication efficiency • Churn tolerant • Anonymity • Accountability • Evaluation • Conclusions
Organization • Motivation • Existing Approaches • Dissent – Strong, Scalable Anonymity • Computational efficiency • Communication efficiency • Churn tolerant • Anonymity • Accountability • Evaluation • Conclusions
Tor – The Onion Router Tor is scalable, supports more than 400,000 clients with 1,000 clients per server Server 02 Server 00 Server 01 Meet tonight at 7 Server 10 Server 11 Server 12 PM in the park for pizza and beer! Bob Public Server Server 22 Server 20 Server 21 Anonymizing Relays
Tor – The Onion Router Server 02 Server 00 Server 01 Not timing analysis resistant! time Meet tonight at 7 Server 10 Server 11 Server 12 PM in the park for pizza and beer! Aha! Got you! Bob Public Server Server 22 Server 20 Server 21 time Anonymizing Relays State-run ISP
DC-net Cleartext message Traffic analysis resistant since all member transmit 1 equal length messages Alice Bob Carol
DC-net Cleartext message Traffic analysis resistant since all member transmit 1 equal length messages 1 1 0 1 Alice Bob 1 0 0 0 Carol
Practical Considerations Mix-nets Tor DC-nets Strong anonymity √ √ √ 1 Scalability √ Churn tolerant √ √ √ 2 Accountability • Mix-nets / Shuffles – Chaum, Neff, Wikstrom • Onion Routing – Tor and I2P • DC-nets – 1 Herbivore and 2 Dissent v1 • Herbivore supported many concurrent users but distributed amongst many parallel DC-nets thus lacks the “Strength in Numbers” or large anonymity set sizes
Organization • Motivation • Existing Approaches • Dissent – Strong, Scalable Anonymity • Computational efficiency • Communication efficiency • Churn tolerant • Anonymity • Accountability • Evaluation • Conclusions
Key Insight Crystal Brett Anna Ben Bob Alice Amy Carol
Use DC-net style Key Insight anonymity within the Mix-net topology to Server 1 obtain scalability! Server 2 Server 0 Barry Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett
Making Strong Anonymity Scale! • Challenge – tradeoff between scale and strength in anonymity systems favoring scale • Dissent’s solution • Improving Computation Efficiency • Improving Communication Efficiency • Handling Churn • Identifying Disruptions • Maintaining Strong Anonymity
Improving Computational Efficiency
Computational Overhead Computation overhead due to O(N 2 ) secret shares Crystal Brett Crystal Ben Anna Bob Carol Amy Alice Anna Ben Bob Alice Amy Carol
N = 100, Computational Overhead 4950 shared secrets, 9900 RNG operations Computation 5.5 ms/peer overhead due to O(N 2 ) secret shares Crystal Brett Crystal Ben Anna Bob Server 1 Carol Amy Alice Anna Cleartext Ben Server 0 Ciphertext Server 2 Bob Alice Amy Carol
Computational Improvement With M servers and N Server 1 clients… O(M*N) shared Server 2 secrets with M << N Server 0 Each server has N secrets RNG reduction: 1000 << 9900 Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett N = 100 and M = 5, Each client 500 shared secrets, has M secrets 1000 RNG operations
Improving Communication Efficiency
Bandwidth Overhead N = 100, Ciphertexts exchanged in DC-nets: 9900 Computation overhead due to O(N 2 ) secret shares Crystal Brett Bandwidth overhead due to O(N 2 ) communication Anna Ben Crystal Ben Anna Bob Brett Carol Amy Alice Bob Cleartext Alice Amy Carol
Bandwidth Efficiency Brett Earlier DC-nets had O(N 2 ) Bob Alex Christine communication cost Crystal Server 1 Anna Barry Amy Server 2 Ben Server 1 Carol Server 2 We can construct Alice Server 2 Server 1 Server 0 Server 0 a DC-net aware multicast tree! Server 0 Barry Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett Clients submit their ciphertext upstream to one server
Bandwidth Efficiency Earlier DC-nets had O(N 2 ) communication cost Server 1 Server 0 Server 0 Server 1 Server 1 Server 0 Server 2 Server 2 We can construct Server 1 Server 2 Server 0 Server 2 a DC-net aware Cleartext Cleartext multicast tree! Cleartext N = 100 and M = 5 Ciphertexts exchanged in DC-nets: 9900, Dissent: 205 Barry Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett Clients submit their Servers XOR these Servers XOR these ciphertext upstream to messages to compute the messages together and one server cleartext and distribute it to share with each other their downstream clients
Creating Churn Tolerance
The resulting cleartext Churn Intolerance is garbage due to the dependency on Alice’s Computation secret shares overhead due to O(N 2 ) secret shares Crystal Brett Bandwidth overhead due to O(N 2 ) communication What if Alice left without transferring? Anna Ben Crystal Ben Anna Bob Brett Carol Amy Alice Bob Garbage Alice Amy Carol
The protocol continues Tolerating Churn Server 1 will uninterrupted, since the timeout on Alex servers have yet to compute Server 1 their ciphertext Server 2 Server 0 Barry Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett
Handling Disruptions via Accountability…
DC-net Easily disrupted 1 1 1 0 1 Alice Bob 1 0 0 0 Carol
DC-net – Disruptions Easily disrupted 1 x 1 1 1 0 1 0 Alice Bob 1 0 0 0 How can we prove Bob 0 transmitted the wrong ciphertext without losing anonymity? Carol
How do many members Scheduling share the DC-net without disrupting each other? Anonymizing shuffle produces random Create a permutation and transmission hence the schedule schedule! Bob Carol Alice Key Alice Key Carol Shuffle Key Bob Key Alice Key Carol Key Bob DC-net Slot Carol Slot Alice Slot Bob
DC-net Integrity check (parity bit) 111 x 101 111 110 000 Alice Bob 010 010 110 100 Integrity check failed! Carol
DC-net 111 x 101 111 110 000 Alice Bob 010 010 110 To determine the disruptor Alice needs to 100 anonymously specify a bit that the disruptor “flipped” from 0 -> 1 Carol
Safely Deanonymize a Bit Bob Carol Alice {Bit 1 } Alice 0 Shuffle 0 {Bit 1 } Alice 0 0
DC-net In practice, this is a bit more complicated though the details are in the paper. 111 101 1 with Bob 1 with Alice 1 with Carol 0 with Carol 111 110 000 Alice Bob 010 110 100 1 with Alice 1 with Bob Carol
DC-net In practice, this is a bit more complicated though the details are in the paper. 111 101 1 with Bob 1 with Alice 1 with Carol 0 with Carol 111 110 000 Alice Bob If Carol reveals the shared 010 110 secret, Alice can confirm that Bob disrupted the previous round 100 1 with Alice 1 with Bob Carol
Progress! • We have gained • Improvements in computation and communication • Ability to tolerate churn • Identify disruptors • How does this impact strong anonymity?
DC-net – Anonymity Set Anonymity set size: 8 Anonymity set size: 4 (Honest participants) (Honest participants) Crystal Brett Anna Ben Bob Alice Amy Carol
Dissent retains this feature…
Anonymity set size: 11 Anonymity set size: 7 Dissent – Anonymity Set (Honest participants) (Honest participants) Server 1 Server 2 Server 0 Barry Anna Ben Christine Alice Carol Alex Crystal Bob Amy Brett Secret sharing graph Anonymity set remains prevents the clients equal as long as there upstream server from is 1 honest server deanonymizing it
Organization • Motivation • Existing Approaches • Dissent – Strong, Scalable Anonymity • Computational efficiency • Communication efficiency • Churn resistance • Anonymity • Accountability • Evaluation • Conclusions
Dissent – Prototype • Written in C++ • Qt from networking, serialization, and events processing • Crypto++ as the crypto library
Related Work Herbivore TR‘03 Evaluated only up to 40 members Dissent CCS’10
Scaling to Thousands of Clients CPU Overheads Bandwidth limitations Latency limited 1,000 clients ~1 second > 5,000 concurrent clients!!
CPU Time 5.5 ms/client
Recommend
More recommend
