CS 6290

Privacy Enhancing Technologies

Department of Computer Science

Slides credit in part from A. Juels, D, Song, A. Miller, E. Ben-Sasson, D. Dziembowski,

A. Judmayer, F. Zhang, I. Eyal, J. Poon, F. Greenspan, and B. Krishnamachari, J. Bootle,
A. Chiessa, S. Delaune, E. Sasson, E. Tromer, A. Zohar
CS6290: Privacy Enhancing Technologies
Next, we are going to talk about
privacy in blockchains

CS6290: Privacy Enhancing Technologies

 Motivation
• Theoretic interest in the 1980s
• Establishing relations between fundamental concepts
such as knowledge, interaction, and proof
• The requirement of Verifiable Computation nowadays
• The flourish of Blockchain technology pushes
researchers to implement workable verifiable proof
 Verifiable Computation

much of the cryptography used today

offers security properties for data

confidentiality authenticity
m m
Alice Bob Alice Bob
Enc(m) Sig(m)

what about security properties for computation?

cryptographic proofs offer
privacy-preserving integrity for computation

one of the exciting crypto deployment frontiers today

 Computational Integrity and Privacy (CIP)

A party executing program P on mix of public/private data . . .

• may have incentive to misreport the output (integrity problem),
• may wish to preserve privacy of parts of the data (privacy problem)
• examples: tax reporting, shielded payments, . ..
• the CIP problem: guaranteeing correct output reported, without
compromising privacy

Zero knowledge proofs offer

privacy-preserving integrity for computation (CIP)

one of the exciting crypto deployment frontiers today

CS6290: Privacy Enhancing Technologies

 Who needs cryptographic CIP?
• Trusted parties (TP)? banks, Google, Facebook, Visa, PayPal, . . .
• TPs have served societies for millennia
• TPs want to stay such, so are not incentivized to pay for crypto CIP
• Cryptographic CIP seems computationally costly compared to TP model
(encryption suffices)
• but considering the costs of manual CIP (audits, legislation, regulation),
E. Ben-Sasson

cryptographic CIP is cheap!

• Enter Bitcoin !
• decentralized, “In Crypto we trust”
• huge incentive to compromise integrity (1BTC > 1,000$~10000$)
• privacy crucial for fungibility and business-adoption
• To conclude, ZKP can fit in the decentralized world perfectly

CS6290: Privacy Enhancing Technologies

 Cryptographic Proofs
a powerful defense against malicious behavior
especially in distributed protocols

1980s securely compute y=F(x1,…,xn) via a multi-party protocol

Key properties
[GMW87]
• zero knowledge
passive security active security • proof of knowledge
2010s blockchain technology
I know x
proof
s.t. y=F(x)
Additional key properties
• non-interactive
• publicly verifiable
• succinct (compact proof)
 Cryptographic Proofs
a powerful defense against malicious behavior
especially in distributed protocols

1980s securely compute y=F(x1,…,xn) via a multi-party protocol

zk-SNARK

Key properties
[GMW87]
• zero knowledge
passive security active security
• proof of knowledge
Why?
2010s blockchain technology Relaxed to argument of
knowledge (ARK)
I know x What is ARK?
proof
s.t. y=F(x) See later…
Additional key properties
• non-interactive
• publicly verifiable
• succinct
Introducing Zero Knowledge Proof
(ZKP)
"Zero-knowledge proofs are fascinating and extremely useful constructs.
They are both convincing and yet yield nothing beyond the validity of
the assertion being proved.” O. Goldreich

CS6290: Privacy Enhancing Technologies

Example of ZK: Where is Charlie?

Goal:
• find the reporter Charlie in a
big picture,
• convince the verifier (me) that
1

you have the solution without

revealing it (neither to me, nor
2

to the others).

CS6290: Privacy Enhancing Technologies

Where is Charlie?

CS6290: Privacy Enhancing Technologies

 Where is Charlie?
How can you prove that you know
where is Charlie without saying
nothing about where he is?

Solutions:
1. get a copy of the picture, cut out Charlie and
1

show it to me. 2

2. put a big mask with a window having the

shape of Charlie and show me Charlie
through the window.

CS6290: Privacy Enhancing Technologies

A more useful example

• Alice want to prove to Bob

he knows the solution;
• Alice does not want to
show the solution directly
1

to Bob such that Bob can

2
show it to Charlie.

CS6290: Privacy Enhancing Technologies

 Interactive proof

• The commitment: Alice writes

down the solution on each card
and place them face down, with
the exception of the constraints

• The challenge: Bob can choose whether he wants to check the rows,
the columns, or the blocks. Eventually he picks one of these three
conditions at random.

CS6290: Privacy Enhancing Technologies

 Interactive proof
• Bob decides to choose the row

• Prove: Alice proceeds to place the cards from each row inside an opaque
bag — one bag per row. She gives each bag a thorough shake, making
sure the index cards inside are mixed well and hands them to Bob.

CS6290: Privacy Enhancing Technologies

 Interactive proof
• Verify: Bob opens each bag and verifies that they should
each have exactly 9 cards with all the numbers 1 through 9

• Bob says this proves nothing and he can also do it by placing

the numbers 1 through 9 in each row in any order he’d like
• Alice explains that she couldn’t have known in advance that
Bob would pick the rows. She’s not a mind reader.
CS6290: Privacy Enhancing Technologies
 Making the proof more convincing
• Bob thinks that there is still a chance for Alice to cheat.
How can Alice assure Bob with higher probability?

1. Rinse and repeat: Alice repeats the procedure with Bob — each time
placing the same cards for the same Sudoku problem face down,
but letting Bob pick a different test at random.
1

2. After a long series of tests, Bob is forced to admit that Alice is either
2

an extremely lucky person, or, that she simply has a solution to the
Sudoku problem (or perhaps she could read his thoughts after all).

CS6290: Privacy Enhancing Technologies

 Non-interactive proof
• How about Alice collude with Bob?
• Imagine that they start a Youtube channel live streaming the Sudoku solving. How
can they prove to the audience that they are not cheating?
• A cryptographer Dave presents a incredible new invention : “The Zero-
Knowledge Sudoku Non-Interactive Proof Machine” (or zk-SNIPM as
he like to refer to it).
✓ The Machine was basically an
1

automated version of Alice’s test.

2

✓ Alice, Bob, Dave can set up the

secret series of tests with their
inputs while nobody could fully
control the final result.
CS6290: Privacy Enhancing Technologies
 End of very informal and intuitive
explanation of ZKP

• This sudoku example is inspired by two great papers that

make zero knowledge proofs accessible to a wide audience:
[1] How to Explain Zero Knowledge Protocols to Your Children
(Quisquater et. al.)
1

[2] Cryptographic and Physical Zero-Knowledge Proof Systems for

Solutions of Sudoku Puzzles (Gradwohl et. al.).
2

Playground: Interactive zero knowledge 3-colorability demonstration

Equivalent to Sudoku problem we have explained (NP-complete)

CS6290: Privacy Enhancing Technologies

Zero-Knowledge Proofs
Statement

Witness/Solution

Prover Verifier

CS6290: Privacy Enhancing Technologies

 Zero-Knowledge Proofs
Statement

Completeness:
An honest prover Prover Verifier
convinces the verifier.

CS6290: Privacy Enhancing Technologies

 Zero-Knowledge Proofs
Statement

Soundness:
A dishonest provernever
Completeness: convinces the verifier.
An honest prover Prover Verifier
convinces the verifier. Computational guarantee
-> argument

CS6290: Privacy Enhancing Technologies

 Zero-Knowledge Proofs
Statement

Witness

Soundness:
A dishonest provernever
Completeness: convinces the verifier.
An honest prover Prover Verifier
convinces the verifier. Computational guarantee
Zero-knowledge:
-> argument
Nothing but the truth of the statement is revealed.

CS6290: Privacy Enhancing Technologies

Zero-Knowledge Proofs
Statement

Interaction

Prover Verifier
Computation Communication Computation
Prover Verifier

Cryptographic
Assumption

CS6290: Privacy Enhancing Technologies

 ZKPs: A Concrete Example
Schnorr protocol for the proof scheme ZKPoK{(a) : ga = A},
where g is the generator of a group G of prime order p

CS6290: Privacy Enhancing Technologies 25

 Desirable goals
Apart from completeness, soundness, and zero knowledge, what
are some possible requirements?
• Succinctness — short proofs, fast verification
• compression of computation (like checking the whole blockchain), without compromising
integrity and privacy
• Non-interactive — less communication overhead
• Universality — arbitrary programs (NP/NEXP complete)
• Scalability — efficient prover running-time
• any code you write, I can prove was executed correctly

CS6290: Privacy Enhancing Technologies

 Universality
Why can support arbitrary programs?
• NP-complete
• Sudoku/3-colorability are NP-complete, just like the famous
circuit satisfiability (SAT) problem.
• Solving either Sudoku/3-colorability is essentially as hard as
solving circuit SAT
• More importantly, Turing-complete machine (computer)
can make use of circuit more easily
• Well established theory in terms of computer architectures
▪ CPU instructions, register, memory, I/O

CS6290: Privacy Enhancing Technologies

 AND

Circuit SAT OR
OR
Determining whether a AND
given Boolean circuit has AND AND
an assignment of its inputs
that makes the output true AND
OR NOT
NOT

OR AND NOT OR AND

AND NOT OR NOT AND

x1 x2 x3 x4 x5
CS6290: Privacy Enhancing Technologies
 Slight difference
The underlying cryptographic primitives requires
algebraic representation.
• Arithmetic circuit instead of Boolean circuit
• Addition and multiplication gate instead of AND/NOT

CS6290: Privacy Enhancing Technologies

Zero-Knowledge Proofs for
Correct Program Execution

Registers
Memory
pc r1 r2 r3 … … … … … flag

Primary Input
instruction1
instruction2 Random
Input Tapes Access
Instruction3
Auxiliary Input
TinyRAM …
Program …
…

TinyRAM Instructions include ADD, MULT, XOR,AND,…

CS6290: Privacy Enhancing Technologies

Zero-Knowledge Proofs for
Correct Program Execution

Registers
Memory
pc r1 r2 r3 … … … … … flag

Primary Input
instruction1
instruction2 Random
Input Tapes Access
Instruction3
Auxiliary Input
TinyRAM …
Program …
…

TinyRAM Public Values <-> Statement

CS6290: Privacy Enhancing Technologies

Zero-Knowledge Proofs for
Correct Program Execution

Registers
Memory
pc r1 r2 r3 … … … … … flag

Primary Input
instruction1
instruction2 Random
Input Tapes Access
Instruction3
Auxiliary Input
TinyRAM …
Program …
…

TinyRAM Private Values <-> Prover’sWitness

CS6290: Privacy Enhancing Technologies

Converting TinyRAM verification to circuit satisfiability

CS6290: Privacy Enhancing Technologies

C program

Compiler based on GCC

TinyRAM program
based on theory
Circuit Generator of [BCGT13] arithmetic
circuit
circuit
⨉ +
ZK-SNARK for CircuitSAT +
⨉
based on theory C
of [GGPR13]
[BCIOP13]
CS6290: Privacy Enhancing Technologies
 ZK-SNARK
• Adopted by Zcash in 2014
• SNARK: S stands for succinct, N for non-interactive, ARK for
argument (“fancy” name for computational soundness)
• The proof is short and blazingly fast to be verified
• Non-interactive requires non-transparent trusted setup phase
• Why argument? Succinctness inevitably requires computational
soundness, a relaxed assumption compared to statistical soundness
• Still computationally expensive-ish and bounded by memory

CS6290: Privacy Enhancing Technologies

Table: Execution of same TinyRAM program for 216 cycles (T);
80-bit security level; machine w/ 32 AMD Opteron cores,
clock rate 3.2 GHz, 512 GB RAM.

ZK-SNARK (2014)

Ver. time ∼ 28 min

setup key len ∼ 18.9 GB
time ∼ 18 min
Prov
memory ∼ 216 GB
time
Ver. < 10 ms
dec. comm 230 bytes
comp

time ∼ 28 min

V. total comm
comp ∼ 18.9 GB

CS6290: Privacy Enhancing Technologies

 State-of-the-art ZKPs

Short Trusted
Fast P Fast V Practical?
Proofs Setup?
ZK-SNARK ✓ X ✓ X ✓
Hyrax X X ✓ish ✓ Xish
BulletProof ✓ X ✓ish ✓ ✓ish
ZKB++ X ✓ish ✓ ✓ ✓ish
Ligero Xish ✓ish ✓ ✓ Xish
ZKSTARK ✓ X ✓ ✓ X

CS6290: Privacy Enhancing Technologies

 Bitcoin’s privacy problem
• Bitcoin: decentralized digital currency.
What’s to prevent double-spending?
Solution: broadcast every transaction
into a public ledger (blockchain):
The cost: privacy.
• Consumer purchases (timing, amounts, merchant)
seen by friends, neighbors, and co-workers.
• Account balance revealed in every transaction.
• Merchant’s cash flow exposed to competitors.
 "Those are just addresses."
These are known by everyone you interact with. And literally anyone can analyze the ledger.

addresses Transaction Graph

1ab...
5 2
f3a... 2 1 1
56f... 3
1
112... 4
4 5
9be...

time

transaction graph + side-info → addresses become names of people!

Not just theoretical:
FBI Silk Road investigations, IRS subpoena to Coinbase, deanon studies, …
[Reid Martin 11] [Barber Boyen Shi Uzun 12] [Ron Shamir 12] [Ron Shamir 13] [Meiklejohn
Pomarole Jordan Levchenko McCoy Voelker Savage 13] [Ron Shamir 14]
 Mitigations to the Privacy Problem
Use new address for each payment.
Launder money with others.

1ab... 1 1 9be...
f3a... 0ac...
56f... 432...
⋮ 1 1 ⋮
112... ffa...

"Seems" harder to analyze.

But tracks remain…

[MMLN17]
Recent quantitative results exploiting such tracks. [KFTS17]

Bitcoin history is publicly stored forever.

Methods of analysis only get stronger.
 Fungibility
a dollar is a dollar, regardless of its history
Recognized as crucial property of money 350+ years ago.
(Crawfurd v. The Royal Bank, 1749)

Bitcoin is NOT fungible because

a coin's pedigree is public.
Dangerous consequences:
• ill-defined value
• different people value the same coin differently
• the same person values different coins differently
• heuristic: new coins more valuable than old ones
• central party that determines correct value?
• price discrimination (salary raise → rent hike)
• censorship (miners filter transactions)
 If privacy is so
important why isn't
Bitcoin private?
 Privacy vs Accountability
From Alice From Scrooge … … From Bob
To Bob To Donald … … To Eve
Amount 1 Amount 2 … … Amount 1

How does the world know that Bob has 1 Bitcoin to spend?
Check that he received it, and that he did not spend it.

What if users encrypted their payment transactions?

From Enc(A) From Enc(S) … … From Enc(B)

To Enc(B) To Enc(D) … … To Enc(E)
Amount Enc(1) Amount Enc(2) … … Amount Enc(1)

Not clear how to check a payment's validity.

privacy and accountability seem to be at odds

 Zerocash/Zcash
I. Miers et al.: “Zerocoin: Anonymous Distributed E-
Cash from Bitcoin”, IEEE S&P’ 13
&
E. Ben-Sasson et al.: “Zerocash: Decentralized
Anonymous Payments from Bitcoin”, IEEE S&P’ 14

CS6290: Privacy Enhancing Technologies

 The Basic Intuition
From Enc(A) From Enc(S) From Enc(B) From c1
To Enc(B) To Enc(D) To Enc(E) To c2
Amount Enc(1) Amount Enc(2) Amount Enc(1) Amount c3
Proof π Proof π' Proof π'' Proof π'''

I am publishing three ciphertexts c1,c2,c3.

They contain the encryptions of a sender address,
a receiver address, and a transfer amount respectively.
Moreover, the amount transfered has not been double spent.
I have generated a cryptographic proof π''' that all of this is true.

Q1: what kind of crypto proof?

Q2: what exactly is the statement being proved?
 Attempt #0: template
view of
min min spend min spend blockchain
t t t
Transaction types

type 1

type 2

coin
 Attempt #1: plaintext serial numbers
mint mint spend mint spend view of
min
sn1 min
sn2 spend
sn2 min
sn3 spend
sn1 blockchain
t t t
Transaction types
mint Consume 1 BTC to create a value-1 coin w/ serial number sn.
sn
spend Consume the coin w/ serial number sn.
sn

Good:
cannot double spend

coin Bad:
serial spend linkable to its mint anyone
sn number can spend with sn!
…
 Attempt #2: committed serial numbers
mint mint spend mint spend view of
min
cm1 min
cm2 spend
sn2, r2 min
cm3 spend
sn1, r1 blockchain
t t t
Transaction types
mint Consume 1 BTC to create a value-1 coin w/ commitment cm.
cm
spend Consume the coin w/ serial number sn.
sn, r

Good:
cannot double spend
others can't spend my coins
coin cm commitment
Bad:
COMM r spend linkable to its mint
sn
serial …
number
 Attempt #3: ZKPoK of commitment
mint mint spend mint spend view of
min
cm1 min
cm2 spend
sn2, π2 min
cm3 spend
sn1, π1 blockchain
t t t
Transaction types
mint Consume 1 BTC to create a value-1 coin w/ commitment cm.
cm
spend Consume the coin w/ serial number sn.
sn, π Here is a ZK proof π that I know secret r s.t. [Sander Ta-Shma
CRYPTO 1999]
exists • cm  "list of prior commitments"
well-formed • cm=COMM(sn;r) cm1

CRH
cm2

CRH
Good:
cm3

CRH
cannot double spend
cm4

CRH
root
cm5
others can't spend my coins spend
coin cm

CRH
commitment
cm6 and mint unlinkable
CRH
COMM r cm7 Bad:
CRH
serial cm8 fixed denomination (side channel
sn number that leaks information)
…
 Attempt #4: variable denomination
mint mint spend mint spend view of
cmmin
1,v1,k1,r1 cmmin
2,v2,k2,r2 spend
sn 2, v2, π2 cmmin
3,v3,k3,r3 snspend
1, v1, π1 blockchain
t t t
Transaction types
mint Consume v BTC to create a value-v coin w/ commitment cm.
cm,v,k,r
spend Consume the coin w/ serial number sn.
sn,v, π Here is a ZK proof π that I know secret (r,s) s.t.
exists • cm  "list of prior commitments"
well-formed • cm=COMM(v,k;r) & k=COMM(sn;s)

Good:
cannot double spend
others can't spend my coins
coin cm commitment
spend and mint unlinkable
COMM r variable denomination
value v COMM s Bad:
serial only hides sender
sn number
…
 Attempt #5: payment addresses
mint mint spend mint spend view of
cmmin
1,v1,k1,r1 cmmin
2,v2,k2,r2 spend
sn 2, v2, π2 cmmin
3,v3,k3,r3 snspend
1, v1, π1 blockchain
t t t
Transaction types
mint Consume v BTC to create a value-v coin w/ commitment cm.
cm,v,k,r
spend Consume the coin w/ serial number sn.
sn,v, π Here is a ZK proof π that I know secret for (cm,k,r,s,ρ,apk,ask) s.t.
exists • cm  "list of prior commitments"
well-formed • cm=COMM(v,k;r) & k=COMM(apk,ρ;s)
mine • sn=PRF(ρ;ask) & apk=PRF(0;ask)
Good:
spend and mint unlinkable
variable denomination
coin cm commitment
address Question:
COMM r sn serial apk spending process not complete, i.e., burn a
number
value v COMM s PRF ask PRF
coin and create another one that the payee
public
secret can use
key
apk ρ key 0
 Attempt #6: direct payments
mint mint spend mint spend view of
cmmin
1,v1,k1,r1 cmmin
2,v2,k2,r2 snspend
2, cm4, π2 cmmin
3,v3,k3,r3 snspend
4, cm5, π4 blockchain
t t t
Transaction types
mint Consume v BTC to create a value-v coin w/ commitment cm.
cm,v,k,r
spend Consume coin w/ serial number snA & create coin w/ commitment cmB.
snA,cmB, π Here is a ZK proof π that I know secret (cmA,vA,kA,rA,sA,ρA,apkA,askA) s.t.
exists • cmA  "list of prior commitments" (cmB,vB,kB,rB,sB,ρB,apkB)
well-formed • cmA=COMM(vA,kA;rA) & kA=COMM(apkA,ρA;sA)
mine • snA=PRF(ρA;askA) & apkA=PRF(0;askA) send out-of-band
well-formed • cmB=COMM(vB,kB;rB) & kB=COMM(apkB,ρB;sB)
or via blockchain

same value • vA=vB Good:

coin cm commitment address cannot double spend
COMM sn serial apk
others can't spend my coins
r number spend and mint unlinkable
value v COMM s PRF ask PRF variable denomination
public
secret hides sender, receiver, amt
key
apk ρ key 0 Bad: join and split coins?
 Sketch of Final Design
mint mint pour mint pour view of
cm1,v1,k1,r1 cm2,v2,k2,r2 sn1 cm3 cm5,v5,k5,r5 sn3 cm6
blockchain
sn2 cm4 sn5 cm7
Transaction types π π’
mint
cm,v,k,r Consume v BTC to create a value-v coin w/ commitment cm.

pour Consume (my) input coins w/ serial numbers snA and snB in order to
snA cmC create two output coins (maybe not mine) w/ commitments cmC and cmD.

snB cmD Here is a ZK proof π that I know secrets that demonstrate that
π • the input coins were minted at some point in the past,
• the output coins are well-formed,
• balance is preserved.
Single tx type for:
coin cm commitment
address ✓simple payments
COMM r sn serial apk ✓join coins
number
value v COMM s PRF ask PRF ✓split coins
secret ✓pay transaction fees
public
key
apk ρ key 0
 Proof-of-concept implementation
mint
v Mint
cm,v,k,r
20μs 70B

old coin info pour

Pour snA,cmC, π
new coin info snB,cmD, ..
1m
1KB
VerTx acc/rej
libzerocash
10ms
Mint, Pour, VerifyTx

arithmetic circuit 4 million arithmetic gates

for Pour NP statement
hand optimized COMM
libsnark std crypto Merkle Tree Path
highly-optimized C++ hashing, PRF
ZK-SNARK library encryption, …

CS6290: Privacy Enhancing Technologies

 Beyond Privacy & Fungibility
pour I'm consuming my unspent coins in order to create
snA cmC new coins in a way that value is preserved.
I'm not revealing the value, sender, or receiver.
snB cmD
π & the receiver was a 501(c) organization but
I am not revealing which one

& the value transfered lies in [10,20]

Exciting research direction:

Which policies are desirable (and feasible!)

to balance privacy/fungibility and oversight/accountability?
 The Pain of Public Parameters
Recall that practical constructions of ZK-SNARKs need a trusted party to
generate parameters for proving/verifying statements.
F

pkF Trusted Generator vkF

Parameter compromise
allows creating valid proofs
for false statements
(but privacy is not broken)
Given this public input x,
I know a secret input w
s.t. F(x,w)=true.

x,π

Who generates the parameters??

One approach: a set of people via a distributed protocol.
Namely, via secure multi-party computation.
 Idea: Multi-Party Computation

S1 S2 S3 S4

Multi-Party Protocol

params

- If ANY of the N parties deletes their “toxic waste”, then params is OK

- Any of the N parties may (trust assumption in MPC)

CS6290: Privacy Enhancing Technologies

 Multi-Party Computation Ceremony
Run by ZECC during October 22—23,
2016. Main ingredients:

• n-party MPC protocol that is secure against ≤n-1 corruptions

[BCGTV15][BGG16]
• extensive threat modeling and security engineering

airgap between network machines

and compute machines
n=6 geographically distributed participants
(including one security company,
and a mobile station)

publicly-verifiable audit trail,

in a hash chain stored on Twitter
and the Internet Archive

video documentation from most participants

including destruction of compute nodes
 Related References
• Gideon Greenspan. “MultiChain Private Blockchain — White Paper”,
online at https://www.multichain.com/download/MultiChain-White-
Paper.pdf
• Elli Androulaki et al. “Hyperledger fabric: a distributed operating system
for permissioned blockchains”, in Proc. of EuroSys 18
• O. Goldreich. Foundations of Cryptography — Volume I (Basic Tools), in
Cambridge University Press, 2001.
• O. Goldreich. “Zero knowledge twenty years after their invention.”
Tutorial at FOCS `02.
• Eli Ben-Sasson et al. “Succint non-interactive zero knowledge for a von
Neumann Architecture”, in Proc. of USENIX Security 14.
• Jens Groth. “On the size of pairing-based non-interactive arguments”, in
Proc. of EUROCRYPT 16.

CS6290: Privacy Enhancing Technologies