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

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

?!?

0VUIC9zZW5zaXRpdmU

…but does that hide enough? With PKE, we can hide the data…

2

(pk, sk) pk

…"

Time From To Size 10:12 Alice Bob 2543 B 10:27 Carol Alice 567 B 10:32 Alice Bob 450 B 10:35 Bob Alice 9382 B

3

Time From To Size 10:12 Alice taxfraud@stanford.edu 2543 B 10:27 Carol Alice 567 B 10:32 Alice Bob 450 B 10:35 Bob Alice 9382 B

[cf. Ed Felten’s testimony before the House
 Judiciary Committee, 2 Oct 2013]

…"

Hiding the data is necessary, but not sufficient

4

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

First Attempt: Tor

[Dingledine,
 Mathewson,
 Syverson 2004]

6

“Onion”
 encryption

Passive network adversary can correlate flows! Is this attack realistic?

[Murdoch and
 Danezis 2005] [Bauer et al. 2007]

7

A well-placed adversary need control few links

[Murdoch and Zieliński 2007]

8

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

Outline

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

10

Outline

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

11

Reframe the Problem

"

Writing “privately” to a database Posting anonymously to a bulletin board

12

Goal

13

The “Anonymity Set”

Goal

14

+

Goal

15

To: taxfraud@stanford.edu Protest will be held tomo… See my cat photos at w…

DB does not learn who wrote which message

(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’ qi

Goals

• 1. Correctness
• 2. Write-anonymity
• 3. Disruption resistance

17

Goal 1: Correctness

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

18

n

X

i=1

mie`i (m1, `1), . . . , (mn, `n)

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

Challenger Adversary Let n = number of clients total

(qi, ˆ qi) ←

π

← Query(mi, `i)

For :

Choose on elements of H

H ⊆ [n] s.t. |H| ≥ 2 {(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H}

21

Challenger Adversary Let n = number of clients total

(qi, ˆ qi) ← ← Query(mi, `i)

For :

π

Choose perm 


• n elements of H

H ⊆ [n] s.t. |H| ≥ 2 {(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H} {ˆ qi | i 62 H}

22

Challenger Adversary Let n = number of clients total

(qi, ˆ qi) ← ← Query(mi, `i)

For :

s ← Update(ˆ

π

Choose perm 


• n elements of H

H ⊆ [n] s.t. |H| ≥ 2 {(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H} {ˆ qi | i 62 H}

23

(qi, ˆ qi) ← ← Query(mi, `i)

For :

s ← Update(ˆ

date(ˆ q1, . . . , ˆ qn)

π

Choose perm 


• n elements of H

H ⊆ [n] s.t. |H| ≥ 2 {(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H} {ˆ qi | i 62 H}

24

(qi, ˆ qi) ← ← Query(mi, `i)

For :

s ← Update(ˆ

date(ˆ q1, . . . , ˆ qn)

s, π

π

Choose perm 


• n elements of H

{(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H} {ˆ qi | i 62 H}

Queries in H updated according to permutation π

25

(qi, ˆ qi) ← ← Query(mi, `i)

For :

s ← Update(ˆ

date(ˆ q1, . . . , ˆ qn)

s, π

π

Choose perm 


• n elements of H

{(mi, `i) | i ∈ H}

i ∈ H

{qπ(i) | i ∈ H} {ˆ qi | i 62 H}

π∗

Adv should not be able to distinguish between real π and random π*

Choose perm 


• n elements of H

π∗

Intuition: The scheme hides “who wrote what” (which query corresponds to which message)

Goal 3: Disruption Resistance

Intuition: each query should change at most

• ne 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

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

• f k-1 servers

(2,1)-Private
 “Straw man”
 Scheme


[Chaum ‘88]

28

SX SY

29

SX SY

“Straw man”
 Scheme

30

SX SY

mA ∈ F

Write msg mA into DB row 3

“Straw man”
 Scheme

31

SX SY

mA

“Straw man”
 Scheme

“Straw man”
 Scheme

32

SX SY

mA r1 r2 r3 r4 r5

“Straw man”
 Scheme

33

SX SY

mA r1 r2 r3 r4 r5

• r1
• r2

mA -r3

• r4
• r5
• =

“Straw man”
 Scheme

34

SX SY

r1 r2 r3 r4 r5

• r1
• r2

mA -r3

• r4
• r5

35

SX SY

r1 r2 r3 r4 r5

• r1
• r2

mA -r3

• r4
• r5

“Straw man”
 Scheme

36

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

“Straw man”
 Scheme

37

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

mB

“Straw man”
 Scheme

“Straw man”
 Scheme

38

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

mB s1 s2 s3 s4 s5

• s1
• s2
• s3
• s4

mB -s5

• =

“Straw man”
 Scheme

39

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

s1 s2 s3 s4 s5

• s1
• s2
• s3
• s4

mB -s5

40

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

s1 s2 s3 s4 s5

• s1
• s2
• s3
• s4

mB -s5

“Straw man”
 Scheme

41

SX

r1 + s1 r2 + s2 r3 + s3 r4 + s4 r5 + s5

SY

• r1 - s1
• r2 - s2
• r3 - s3 + mA
• r4 - s4
• r5 - s5 - mB

“Straw man”
 Scheme

42

SX

r1 + s1 r2 + s2 r3 + s3 r4 + s4 r5 + s5

SY

• r1 - s1
• r2 - s2
• r3 - s3 + mA
• r4 - s4
• r5 - s5 - mB

“Straw man”
 Scheme

43

SX

r1 + s1 r2 + s2 r3 + s3 r4 + s4 r5 + s5

SY

• r1 - s1
• r2 - s2
• r3 - s3 + mA
• r4 - s4
• r5 - s5 - mB

“Straw man”
 Scheme

44

SX

r1 + s1 r2 + s2 r3 + s3 r4 + s4 r5 + s5

SY

• r1 - s1
• r2 - s2
• r3 - s3 + mA
• r4 - s4
• r5 - s5 - mB

“Straw man”
 Scheme

45

SX

r1 + s1 r2 + s2 r3 + s3 r4 + s4 r5 + s5

SY

• r1 - s1
• r2 - s2
• r3 - s3 + mA
• r4 - s4
• r5 - s5 - mB

At the end of the day, servers combine DBs to reveal plaintext

+ =

mA mB

“Straw man”
 Scheme


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

Extensions

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

47

Outline

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

48

Limitations of the “Straw man”

• 1. O(L) communication cost
• 2. Collisions
• 3. Malicious clients

49

Limitations of the “Straw man”

• 1. O(L) communication cost
• 2. Collisions
• 3. Malicious clients

50

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

(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

m ∈ F ; ` ∈ [L]

Goal:

52

(k,t)-Distributed Point Functions

Correctness: (k,t)-Privacy: [In a minute]

53

Sum of the Eval()

• utputs will be zero

everywhere, except at position l

DPF Correctness

54

…

KeyGen(

en(m, `)

q1 q2 qk Eval … Eval Eval

x1

+

x2 xk

+ …

m

=

(k,t)-Distributed Point Functions

(k,t)-Privacy: Can simulate the distribution

• f any subset S of at most t DPF keys

[ Intuition: t keys leak nothing about m or ]

55

(q1, . . . , qk) ← KeyGen(m, `) {qi}i∈S ≈c Sim(S) ∀S ⊂ [k] s.t. |S| ≤ t

56

SX SY

DPFs Reduce Bandwidth Cost

Eval( ) Eval( )

57

SX SY

DPFs Reduce Bandwidth Cost

r1 r2 r3 r4 r5

• r1
• r2

mA -r3

• r4
• r5

58

Alice sends
 bits

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(L1/2)-length keys based on PIR of Chor and Gilboa (’97)

(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

Idea: – Represent Eval() output as a matrix – Keys can be length of row

62

Output will sum to m at = (i, j)

(2,1)-DPF Construction

63

k1 k2 k3 k4 k5

v

1 1 1

Using as the field Key = (b, k, v), where each has length O(

√ L)

F2

Sampled at random

k1 k2* k3 k4 k5

v

1 1

(2,1)-DPF Construction

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1 G(k1) G(k2) G(k3) G(k4) G(k5) G(k1) G(k2*) G(k3) G(k4) G(k5)

64

G() is a PRG mapping keys k to L1/2 bits

(2,1)-DPF Construction

65

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1 G(k1) G(k2) + v G(k3) + v G(k4) G(k5) + v G(k1) G(k2*) G(k3) + v G(k4) G(k5) + v

(2,1)-DPF Construction

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1 G(k1) G(k2) + v G(k3) + v G(k4) G(k5) + v G(k1) G(k2*) G(k3) + v G(k4) G(k5) + v

Outputs are equal everywhere except at row 2

66

(2,1)-DPF Construction

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1 G(k1) G(k3) + v G(k4) G(k5) + v G(k1) G(k3) + v G(k4) G(k5) + v

Outputs sum to zero everywhere except at row 2

G(k2) + v G(k2*)

67

(2,1)-DPF Construction

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1 G(k1) G(k3) + v G(k4) G(k5) + v G(k1) G(k3) + v G(k4) G(k5) + v G(k2) + v G(k2*)

Construct v as: v = G(k2) + G(k2*) + m " ej

68

G(k1) G(k2) + v G(k3) + v G(k4) G(k5) + v G(k1) G(k2*) G(k3) + v G(k4) G(k5) + v

+ =

00000…00000 0000000m000 00000…00000 00000…00000 00000…00000

69

Challenge 1: Bandwidth Efficiency

• Brings comm cost down to O(L1/2)

– Just requires PRG — fast!

• Recursive application of the same trick

– Key size down to polylog(L) [GI’14]

k1 k2 k3 k4 k5

v

1 1 1

70

New DPF Construction

Given a seed-homomorphic PRG

G(s1) + G(s2) = G(s1 + s2)

we build a (k, k-1)-private DPF


[NPR’99] [BLMR’13] [BP’14] [BV’15]


! Privacy holds even if all but


• ne 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

73

Challenge 2: Collisions

• Clients pick write location at random
• Two honest clients may write into 


the same location

74

mA

Challenge 2: Collisions

• Clients pick write location at random
• Two honest clients may write into 


the same location

75

mA + mB

Challenge 2: Collisions

• Clients pick write location at random
• Two honest clients may write into 


the same location Instead of getting mA,
 mB, get the sum mA + mB

76

mA + mB

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

c = m1 + m2

77

Challenge 2: Collisions

Idea: To handle 2-collisions, can
 code message m as: (m, m2)

[Let ]

After a 2-collision, DBs recover the values: Given c1 and c2 can recover m1 and m2

c1 = m1 + m2 c2 = m2

1 + m2 2

78

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%

Limitations of the “Straw man”

• 1. O(L) communication cost
• 2. Collisions
• 3. Malicious clients

80

Challenge 3: Malicious Clients

81

SX

r1 r2 r3 r4 r5

SY

• r1
• r2
• r3+mA
• r4
• r5

One malicious client can corrupt the entire DB!

b1 b2 b3 b4 b5 a1 a2 a3 a4 a5

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

DB Server X DB Server Y Auditor

83

DB Server X DB Server Y Auditor

84

DB Server X DB Server Y Auditor

85

DB Server X DB Server Y Auditor Auditor

k1 k2 k3 k4 k5

v

1 1 1 k1 k2* k3 k4 k5

v

1 1

86

DB Server X DB Server Y Auditor Auditor

k1 k2 k3 k4 k5 1 1 1 k1 k2* k3 k4 k5 1 1

87

DB Server X DB Server Y Auditor Auditor

0 | k1 1 | k2 1 | k3 0 | k4 1 | k5 0 | k1 0 | k2* 1 | k3 0 | k4 1 | k5

88

DB Server X DB Server Y Auditor

a1 a2 a3 b1 b2 b3

89

DB Server X DB Server Y Auditor

a1

• ffset

a2 a3 b1 b2 b3

90

DB Server X DB Server Y Auditor

• ffset

a1 a2 a3 b2 b3 b1

91

DB Server X DB Server Y Auditor

h1, h2, h3

a1 a2 a3 b2 b3 b1

92

DB Server X DB Server Y Auditor

h1(a1) h2(a2) h3(a3) h2(b2) h3(b3) h1(b1)

h1, h2, h3

93

DB Server X DB Server Y Auditor

h1(a1) h2(a2) h3(a3) h2(b2) h3(b3) h1(b1)

94

DB Server X DB Server Y Auditor

h1(a1) h2(a2) h3(a3) h2(b2) h3(b3) h1(b1)

95

Auditor

r3 r1 r2 r1 r2 r3

Equal almost everywhere?

96

DB Server X DB Server Y Auditor

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
• n a single server

# Main bottleneck is PRG expansion

100

Throughput


(anonymous Twitter)

At large table sizes, PRG cost dominates

101

Outline

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

102

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

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

– Stillbarriers to practicality (+ open problems)

104

Questions?

105

106