Riposte: an Anonymous Messaging System that 'Hides the Metadata' - PowerPoint PPT Presentation

DPF Correctness Eval x 1 q 1 en ( m, ` ) + x 2 Eval q 2 … KeyGen ( … … + x k Eval q k = 0 0 m 0 0 0 54

(k,t)-Distributed Point Functions (k,t)- Privacy : Can simulate the distribution of any subset S of at most t DPF keys ( q 1 , . . . , q k ) ← KeyGen ( m, ` ) ∀ S ⊂ [ k ] { q i } i ∈ S ≈ c Sim ( S ) s.t. | S | ≤ t [ Intuition : t keys leak nothing about m or ] 55

S X S Y 0 0 Eval ( ) Eval ( ) 0 0 0 0 0 0 0 0 DPFs Reduce Bandwidth Cost 56

S X S Y 0 r 1 - r 1 0 0 r 2 - r 2 0 0 r 3 m A - r 3 0 0 r 4 - r 4 0 0 r 5 -r 5 0 DPFs Reduce Bandwidth Cost 57

Alice sends 
 bits 58

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 I will present a (2,1)-DPF with O(L 1/2 )-length keys based on PIR of Chor and Gilboa (’97) 59

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

(2,1)-DPF Construction 61

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

(2,1)-DPF Construction Sampled at F 2 Using as the field random √ Key = ( b , k , v ), where each has length O ( L ) 0 k 1 0 k 1 1 k 2 0 k 2 * 1 k 3 1 k 3 0 k 4 0 k 4 1 k 5 1 k 5 v v 63

(2,1)-DPF Construction G() is a PRG mapping keys k to L 1/2 bits G(k 1 ) 0 k 1 0 k 1 G(k 1 ) 1 k 2 G(k 2 ) G(k 2 *) 0 k 2 * 1 k 3 G(k 3 ) 1 k 3 G(k 3 ) G(k 4 ) 0 k 4 0 k 4 G(k 4 ) 1 k 5 G(k 5 ) 1 k 5 G(k 5 ) v v 64

(2,1)-DPF Construction G(k 1 ) 0 k 1 0 k 1 G(k 1 ) 1 k 2 G(k 2 ) + v G(k 2 *) 0 k 2 * 1 k 3 G(k 3 ) + v 1 k 3 G(k 3 ) + v G(k 4 ) 0 k 4 0 k 4 G(k 4 ) 1 k 5 G(k 5 ) + v 1 k 5 G(k 5 ) + v v v 65

(2,1)-DPF Construction Outputs are equal everywhere except at row 2 G(k 1 ) 0 k 1 0 k 1 G(k 1 ) 1 k 2 G(k 2 ) + v G(k 2 *) 0 k 2 * 1 k 3 G(k 3 ) + v 1 k 3 G(k 3 ) + v G(k 4 ) 0 k 4 0 k 4 G(k 4 ) 1 k 5 G(k 5 ) + v 1 k 5 G(k 5 ) + v v v 66

(2,1)-DPF Construction Outputs sum to zero everywhere except at row 2 G(k 1 ) 0 k 1 0 k 1 G(k 1 ) 1 k 2 G(k 2 ) + v G(k 2 *) 0 k 2 * 1 k 3 G(k 3 ) + v 1 k 3 G(k 3 ) + v G(k 4 ) 0 k 4 0 k 4 G(k 4 ) 1 k 5 G(k 5 ) + v 1 k 5 G(k 5 ) + v v v 67

(2,1)-DPF Construction Construct v as: v = G(k 2 ) + G(k 2 *) + m " e j G(k 1 ) 0 k 1 0 k 1 G(k 1 ) 1 k 2 G(k 2 ) + v G(k 2 *) 0 k 2 * 1 k 3 G(k 3 ) + v 1 k 3 G(k 3 ) + v G(k 4 ) 0 k 4 0 k 4 G(k 4 ) 1 k 5 G(k 5 ) + v 1 k 5 G(k 5 ) + v v v 68

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

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] 0 k 1 1 k 2 1 k 3 v 0 k 4 1 k 5 70

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

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

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

Challenge 2: Collisions • Clients pick write location at random • Two honest clients may write into 
 the same location � 0 0 m A 0 0 74

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

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

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

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: c 1 = m 1 + m 2 c 2 = m 2 1 + m 2 2 Given c 1 and c 2 can recover m 1 and m 2 78

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

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

One malicious S X S Y client can corrupt r 1 - r 1 the entire DB! r 2 - r 2 r 3 - r 3 + m A r 4 - r 4 r 5 - r 5 a 1 b 1 Challenge 3: a 2 b 2 Malicious a 3 b 3 Clients a 4 b 4 a 5 b 5 81

Challenge 3: Malicious Client 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] 82

Auditor DB Server X DB Server Y 83

Auditor DB Server X DB Server Y 84

Auditor DB Server X DB Server Y 85

0 k 1 0 k 1 Auditor Auditor 1 k 2 0 k 2 * 1 k 3 1 k 3 v v 0 k 4 0 k 4 1 k 5 1 k 5 DB Server X DB Server Y 86

0 k 1 0 k 1 Auditor Auditor 1 k 2 0 k 2 * 1 k 3 1 k 3 0 k 4 0 k 4 1 k 5 1 k 5 DB Server X DB Server Y 87

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

Auditor a 1 a 2 a 3 b 1 b 2 b 3 DB Server X DB Server Y 89

Auditor a 1 a 2 a 3 b 1 b 2 b 3 offset DB Server X DB Server Y 90

Auditor a 3 a 1 b 2 b 3 b 1 a 2 offset DB Server X DB Server Y 91

Auditor a 3 a 1 b 2 b 3 b 1 a 2 h 1 , h 2 , h 3 DB Server X DB Server Y 92

Auditor h 3 ( a 3 ) h 1 ( a 1 ) h 2 ( b 2 ) h 3 ( b 3 ) h 1 ( b 1 ) h 2 (a 2 ) h 1 , h 2 , h 3 DB Server X DB Server Y 93

Auditor h 3 ( a 3 ) h 1 ( a 1 ) h 2 ( b 2 ) h 3 ( b 3 ) h 1 ( b 1 ) h 2 ( a 2 ) DB Server X DB Server Y 94

Auditor h 2 ( b 2 ) h 3 ( b 3 ) h 1 ( b 1 ) h 2 ( a 2 ) h 3 ( a 3 ) h 1 ( a 1 ) DB Server X DB Server Y 95

Equal almost Auditor everywhere? r 1 r 2 r 3 r 1 r 2 r 3 96

Auditor DB Server X DB Server Y 97

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

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

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