1. Riposte: an Anonymous Messaging System that 'Hides the Metadata' Charles River Crypto Day 20 February 2015 Henry Corrigan-Gibbs Joint work with Dan Boneh and David Mazières To appear at IEEE Security and Privacy 2015 1

2. ?!? 0VUIC9zZW5zaXRpdmU …but does that hide enough? With PKE, we can hide the data… 2 (pk, sk)pk

3. … TimeFromToSize 10:12AliceBob2543 B 10:27CarolAlice567 B 10:32AliceBob450 B 10:35BobAlice9382 B 3

4. TimeFromToSize 10:12Alicetaxfraud@stanford.edu2543 B 10:27CarolAlice567 B 10:32AliceBob450 B 10:35BobAlice9382 B [cf. Ed Felten’s testimony before the House Judiciary Committee, 2 Oct 2013] … Hiding the data is necessary, but not sufficient 4

5. Focus of this talk Goal: post “anonymously” to a public bulletin board Building block for many problems related to “hiding the metadata”  E-voting  Anonymous surveys  Private messaging, etc. 5

6. First Attempt: Tor [Dingledine, Mathewson, Syverson 2004] 6 “Onion” encryption

7. Passive network adversary can correlate flows! Is this attack realistic? [Murdoch and Danezis 2005] [Bauer et al. 2007] 7

8. A well-placed adversary need control few links [Murdoch and Zieliński 2007] 8

9. Tor is practical at Internet scale … but its security properties are unclear We design an anonymous messaging system that: 1) satisfies clear security goals, 2) handles millions of users in an “anonymous Twitter” system. 9

10. Outline Motivation Definitions and a “Straw man” scheme Technical challenges Evaluation Conclusions 10

11. Outline Motivation Definitions and a “Straw man” scheme Technical challenges Evaluation Conclusions 11

12. Reframe the Problem ≅ ≅ Writing “privately” to a database Posting anonymously to a bulletin board 12

13. Goal 13 The “Anonymity Set”

14. Goal 14

15. + Goal 15 0 To: taxfraud@stanford.edu 0 Protest will be held tomo… See my cat photos at w… 0 DB does not learn who wrote which message

16. (k,t)-Write-Anonymous DB Scheme k = (# of servers), t = (# malicious servers) [Gen query to write m into row l of DB] [Apply query to state of server i] [Combine server states to reveal plaintext DB] 16 s s s’ qiqi

17. Goals 1.Correctness 2.Write-anonymity 3.Disruption resistance 17

18. Goal 1: Correctness Informal: Output DB should be result of applying queries to DB state. If queries are: then result of Reveal() is: 18

19. Goal 2: Write-Anonymity Informal: coalition of t malicious servers and any number of malicious clients should not learn who wrote what to the DB. I will present the [simplified] two-server definition with one malicious server. 19

20. 20 Challenger Adversary Let n = number of clients total For : Choose on elements of H

21. 21 Challenger Adversary Let n = number of clients total For : Choose perm on elements of H

22. 22 Challenger Adversary Let n = number of clients total For : Choose perm on elements of H

23. 23 Challenger Adversary Let n = number of clients total For : Choose perm on elements of H

24. (k,t)-Write-Private Database Scheme Challenger Adversary 24 Let n = number of clients total For : Choose perm on elements of H Queries in H updated according to permutation π

25. (k,t)-Write-Private Database Scheme Challenger Adversary 25 Let n = number of clients total For : Choose perm on elements of H Adv should not be able to distinguish between real π and random π* Choose perm on elements of H Intuition: The scheme hides “who wrote what” (which query corresponds to which message) Intuition: The scheme hides “who wrote what” (which query corresponds to which message)

26. Goal 3: Disruption Resistance Intuition: each query should change at most one DB row—prevent disruption Informal: An adversary cannot generate N “valid” queries that affect > N rows [We defer the definition a “valid” query for now…] 26

27. Privacy-Preserving DB Schemes ORAM [GO’96] / Group ORAM [GOMT’11] –CPU(s) writing to RAM Private Info Retrieval (PIR) [CGKS’97] –Client reading from DB shared across servers Private Info Storage [OS’97] –Client writing to DB shared across servers This work: Many clients (incl malicious ones) writing to DB shared across servers 27 Ideally: for all k, tolerate compromise of k-1 servers

28. (2,1)-Private “Straw man” Scheme [Chaum ‘88] 28 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0

29. 29 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 “Straw man” Scheme

30. 30 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 Write msg m A into DB row 3 “Straw man” Scheme

31. 31 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 0 0 mAmA 0 0 “Straw man” Scheme

32. 32 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 0 0 mAmA 0 0 r1r1 r2r2 r3r3 r4r4 r5r5

33. “Straw man” Scheme 33 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 0 0 mAmA 0 0 r1r1 r2r2 r3r3 r4r4 r5r5 -r1-r1 -r2-r2 m A -r 3 -r4-r4 -r 5 - =

34. “Straw man” Scheme 34 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 r1r1 r2r2 r3r3 r4r4 r5r5 -r1-r1 -r2-r2 m A -r 3 -r4-r4 -r 5

35. 35 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 r1r1 r2r2 r3r3 r4r4 r5r5 -r1-r1 -r2-r2 m A -r 3 -r4-r4 -r 5 “Straw man” Scheme

36. 36 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 “Straw man” Scheme

37. 37 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 0 0 0 0 mBmB “Straw man” Scheme

38. 38 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 0 0 0 0 mBmB s1s1 s2s2 s3s3 s4s4 s5s5 -s1-s1 -s2-s2 -s3-s3 -s4-s4 m B - s 5 - =

39. “Straw man” Scheme 39 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 s1s1 s2s2 s3s3 s4s4 s5s5 -s1-s1 -s2-s2 -s3-s3 -s4-s4 m B - s 5

40. 40 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 s1s1 s2s2 s3s3 s4s4 s5s5 -s1-s1 -s2-s2 -s3-s3 -s4-s4 m B - s 5 “Straw man” Scheme

41. 41 SXSX r 1 + s 1 r 2 + s 2 r 3 + s 3 r 4 + s 4 r 5 + s 5 SYSY -r 1 - s 1 -r 2 - s 2 -r 3 - s 3 + m A -r 4 - s 4 -r 5 - s 5 - m B “Straw man” Scheme

42. 42 SXSX r 1 + s 1 r 2 + s 2 r 3 + s 3 r 4 + s 4 r 5 + s 5 SYSY -r 1 - s 1 -r 2 - s 2 -r 3 - s 3 + m A -r 4 - s 4 -r 5 - s 5 - m B “Straw man” Scheme

43. 43 SXSX r 1 + s 1 r 2 + s 2 r 3 + s 3 r 4 + s 4 r 5 + s 5 SYSY -r 1 - s 1 -r 2 - s 2 -r 3 - s 3 + m A -r 4 - s 4 -r 5 - s 5 - m B “Straw man” Scheme

44. 44 SXSX r 1 + s 1 r 2 + s 2 r 3 + s 3 r 4 + s 4 r 5 + s 5 SYSY -r 1 - s 1 -r 2 - s 2 -r 3 - s 3 + m A -r 4 - s 4 -r 5 - s 5 - m B “Straw man” Scheme

45. 45 SXSX r 1 + s 1 r 2 + s 2 r 3 + s 3 r 4 + s 4 r 5 + s 5 SYSY -r 1 - s 1 -r 2 - s 2 -r 3 - s 3 + m A -r 4 - s 4 -r 5 - s 5 - m B At the end of the day, servers combine DBs to reveal plaintext + = 0 0 mAmA 0 mBmB “Straw man” Scheme

46. First-Attempt Scheme: Properties Correctness — By construction Write-Anonymity — Given output vector, servers can simulate their view of the protocol run Practical Efficiency — Almost no “heavy” computation involved 46

47. Extensions Use k > 2 servers  secure against k-1 evil servers Use a large- characteristic field  e.g., email-length rows 47

48. Outline Motivation Definitions and a “Straw man” scheme Technical challenges Evaluation Conclusions 48

49. Limitations of the “Straw man” 1.O(L) communication cost 2.Collisions 3.Malicious clients 49

50. Limitations of the “Straw man” 1.O(L) communication cost 2.Collisions 3.Malicious clients 50

51. Challenge 1: Bandwidth Efficiency In “straw man” design, client sends DB-sized vector to each server Idea: run PIR protocol in reverse to write into DB while sending fewer bits PIR-in-reverse used in Ostrovsky-Shoup ’97 in single-client context We extend their results to a many- client context (with malicious clients) 51

52. (k,t)-Distributed Point Functions We use a generalization of “DPFs” defined by Gilboa and Ishai (2014) Many one-round-trip PIR protocols construct DPFs implicitly Goal: 52

53. (k,t)-Distributed Point Functions Correctness: (k,t)-Privacy: [In a minute] 53 Sum of the Eval() outputs will be zero everywhere, except at position l

54. DPF Correctness 54 … … x1x1 + x2x2 xkxk + … 0 00 0 0m =

55. (k,t)-Distributed Point Functions (k,t)-Privacy: Can simulate the distribution of any subset S of at most t DPF keys [ Intuition: t keys leak nothing about m or l ] 55

56. 56 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 DPFs Reduce Bandwidth Cost

57. 57 SXSX 0 0 0 0 0 SYSY 0 0 0 0 0 DPFs Reduce Bandwidth Cost r1r1 r2r2 r3r3 r4r4 r5r5 -r1-r1 -r2-r2 m A -r 3 -r4-r4 -r 5

58. 58 Alice sends bits

59. Challenge 1: Bandwidth Efficiency We show: a (k, t)-private DPF yields a k-server write-anonymous DB scheme tolerating up to t malicious servers 59 I will present a (2,1)-DPF with O(L 1/2 )-length keys based on PIR of Chor and Gilboa (’97)

60. (2,1)-DPF Construction Idea: – Represent Eval() output as a matrix – Keys can be length of side 60

61. (2,1)-DPF Construction 61

62. (2,1)-DPF Construction Idea: – Represent Eval() output as a matrix – Keys can be length of row 62 Output will sum to m at l = (i, j)

63. (2,1)-DPF Construction 63 k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 Using as the field Key = (b, k, v), where each has length Sampled at random k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1

64. (2,1)-DPF Construction k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 G(k 1 ) G(k 2 ) G(k 3 ) G(k 4 ) G(k 5 ) G(k 1 ) G(k 2 *) G(k 3 ) G(k 4 ) G(k 5 ) 64 G() is a PRG mapping keys k to L 1/2 bits

65. (2,1)-DPF Construction 65 k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 G(k 1 ) G(k 2 ) + v G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 1 ) G(k 2 *) G(k 3 ) + v G(k 4 ) G(k 5 ) + v

66. (2,1)-DPF Construction k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 G(k 1 ) G(k 2 ) + v G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 1 ) G(k 2 *) G(k 3 ) + v G(k 4 ) G(k 5 ) + v Outputs are equal everywhere except at row 2 66

67. (2,1)-DPF Construction k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 G(k 1 ) G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 1 ) G(k 3 ) + v G(k 4 ) G(k 5 ) + v Outputs sum to zero everywhere except at row 2 G(k 2 ) + v G(k 2 *) 67

68. (2,1)-DPF Construction k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 G(k 1 ) G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 1 ) G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 2 ) + v G(k 2 *) Construct v as: v = G(k 2 ) + G(k 2 *) + m  e j 68

69. G(k 1 ) G(k 2 ) + v G(k 3 ) + v G(k 4 ) G(k 5 ) + v G(k 1 ) G(k 2 *) G(k 3 ) + v G(k 4 ) G(k 5 ) + v += 00000…00000 0000000m000 00000…00000 69

70. Challenge 1: Bandwidth Efficiency Brings comm cost down to O(L 1/2 ) –Just requires PRG — fast! Recursive application of the same trick –Key size down to polylog(L) [GI’14] k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 70

71. New DPF Construction Given a seed-homomorphic PRG G(s 1 ) + G(s 2 ) = G(s 1 + s 2 ) we build a (k, k-1)-private DPF [NPR’99] [BLMR’13] [BP’14] [BV’15]  Privacy holds even if all but one server is adversarial 71

72. Limitations of the “Straw man” 1.O(L) communication cost 2.Collisions 3.Malicious clients 72

73. Challenge 2: Collisions Clients pick write location l at random Two honest clients may write into the same location l 73 0 0 0 0 0

74. Challenge 2: Collisions Clients pick write location l at random Two honest clients may write into the same location l 74 0 0 mAmA 0 0

75. Challenge 2: Collisions Clients pick write location l at random Two honest clients may write into the same location l 75 0 0 m A + m B 0 0

76. Challenge 2: Collisions Clients pick write location l at random Two honest clients may write into the same location l Instead of getting m A, m B, get the sum m A + m B 76 0 0 m A + m B 0 0

77. Challenge 2: Collisions Straightforward solution: Make DB table large enough to avoid collisions Better solution: Use coding techniques to recover from up to d-way collisions Key idea: even after a collision, learn the sum of colliding writes 77

78. Challenge 2: Collisions Idea: To handle 2-collisions, can code message m as: (m, m 2 ) [Let ] After a 2-collision, DBs recover the values: Given c 1 and c 2 can recover m 1 and m 2 78

79. Challenge 2: Collisions Using coding technique, can tolerate d-collisions for any d For 1% loss rate, 1k users: Naive method: 100k cells Coding method: 6.9k cells 79 Reduces table size by 93%

80. Limitations of the “Straw man” 1.O(L) communication cost 2.Collisions 3.Malicious clients 80

81. Challenge 3: Malicious Clients 81 SXSX r1r1 r2r2 r3r3 r4r4 r5r5 SYSY -r1-r1 -r2-r2 -r3+mA-r3+mA -r4-r4 -r5-r5 One malicious client can corrupt the entire DB! b1b1 b2b2 b3b3 b4b4 b5b5 a1a1 a2a2 a3a3 a4a4 a5a5

82. Goal: Prevent evil client from destroying DB One way to solve this is with NIZKs –Expensive public-key crypto [Golle Juels ‘04] More efficient solution: –Add a third non-colluding “audit” server to get honest majority –Fast, info-theoretic MPC techniques [GMW’87], [CCD’88], [FNW’96] Challenge 3: Malicious Client 82

83. DB Server XDB Server Y Auditor 83

84. DB Server XDB Server Y Auditor 84

85. DB Server XDB Server Y Auditor 85

86. DB Server XDB Server Y Auditor k1k1 k2k2 k3k3 k4k4 k5k5 v 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 v 0 0 1 0 1 86

87. DB Server XDB Server Y Auditor k1k1 k2k2 k3k3 k4k4 k5k5 0 1 1 0 1 k1k1 k2*k2* k3k3 k4k4 k5k5 0 0 1 0 1 87

88. DB Server XDB Server Y Auditor 0 | k 1 1 | k 2 1 | k 3 0 | k 4 1 | k 5 0 | k 1 0 | k 2 * 1 | k 3 0 | k 4 1 | k 5 88

89. DB Server XDB Server Y Auditor a1a1 a2a2 a3a3 b1b1 b2b2 b3b3 89

90. DB Server XDB Server Y Auditor a1a1 offset a2a2 a3a3 b1b1 b2b2 b3b3 90

91. DB Server XDB Server Y Auditor offset a1a1 a2a2 a3a3 b2b2 b3b3 b1b1 91

92. DB Server XDB Server Y Auditor h 1, h 2, h 3 a1a1 a2a2 a3a3 b2b2 b3b3 b1b1 92

93. DB Server XDB Server Y Auditor h1(a1)h1(a1) h 2 (a 2 ) h3(a3)h3(a3)h2(b2)h2(b2)h3(b3)h3(b3)h1(b1)h1(b1) h 1, h 2, h 3 93

94. DB Server XDB Server Y Auditor h1(a1)h1(a1) h2(a2)h2(a2) h3(a3)h3(a3)h2(b2)h2(b2)h3(b3)h3(b3)h1(b1)h1(b1) 94

95. DB Server XDB Server Y Auditor h1(a1)h1(a1) h2(a2)h2(a2) h3(a3)h3(a3) h2(b2)h2(b2)h3(b3)h3(b3)h1(b1)h1(b1) 95

96. Auditor r3r3 r1r1 r2r2 r1r1 r2r2 r3r3 Equal almost everywhere? 96

97. DB Server XDB Server Y Auditor 97

98. Outline Motivation Definitions and a “Straw man” scheme Technical challenges Evaluation Conclusions 98

99. Implementation Implemented the full protocol in Go –2 DB servers + 1 audit server Ran perf evaluation on a network testbed simulating real-world net conditions 99

100. Bottom-Line Result For a DB with 65,000 Tweet-length rows, can process 30 writes/second Can process 1,000,000 writes in 8 hours on a single server  Main bottleneck is PRG expansion 100

101. Throughput (anonymous Twitter) At large table sizes, PRG cost dominates 101

102. Outline Motivation Definitions and a “Straw man” scheme Technical challenges Evaluation Conclusions 102

103. Open Problems 1.Reduce Θ(L) computation cost at server –Using multiple rounds per write? 2.Key-homomorphic DPFs – Another way to reduce cost at server 3.(k, k-1)-private DPFs without PKC –Possible without seed-hom PRGs? 103

104. Conclusion In many contexts, “hiding the metadata” is as important as hiding the data Combination of crypto tools with systems design  1,000,000-user anonymity sets “Multi-user writable PIRs” have applications to private messaging –Still ∃ barriers to practicality (+ open problems) 104

105. Questions? 105

106. 106