CS 378
Digital Cash
Vitaly Shmatikov
slide 1
Digital Cash: Properties
Digital “payment message” with properties of cash
Unforgeable
• Users cannot “mint” valid cash on their own
Anonymous and untraceable
• Cannot link a payment to payer’s identity
• Without this property, might as well use a credit card,
except for micropayments (more on this later)
Does not require online intermediaries
• Accepting merchant does not have to interact with the
bank to verify that user’s payment is valid
slide 2
Overview of the System
Withdraw
digital “coins”
bank
user
Spend coins
Deposit coins
merchant
slide 3
Digital “Coins”
User creates the coin, bank signs it and debits the
coin’s face amount to user’s account
No anonymity from the bank!
Coin
m=(amount, serial number)
bank
Bank can record all serial numbers.
When a coin is presented for
payment by merchant, bank will
know who spent it.
=sigbank(m)
user
Any merchant can verify bank’s
signature on the coin
slide 4
Blind Signatures
User creates a coin
User puts his coin into a digital “envelope”
Bank signs “through” the envelope
• Electronic equivalent of embossing an envelope: bank
signs its contents without learning what they are
User receives the signed envelope and opens it,
extracting bank’s signature on the coin
The coin is signed by the bank, but bank does
not know its number and cannot trace it!
slide 5
RSA Signatures Redux
Public key is (n,e), private key is d
• Main property: for any b, bed mod n  b
• Assume that everybody knows bank’s public key
To sign message m: s = md mod n
• It’s infeasible to compute s on m if you don’t know d
To verify signature s on message m:
se mod n = (md)e mod n  m
• Anyone who knows n and e (public key) can verify
signatures produced with d (private key)
slide 6
Coins with Blind RSA Signatures
[Chaum]
 User creates the coin, blinds it, bank signs it, user
removes blinding and obtains a valid coin
Public key=(n,e)
b is a secret random
multiplier chosen by user
Bank does not see m, so
send amount separately
User can cheat!
r=mbe,
“amount=$10”
bank
For example, amount=$100 in m, but
amount=$10 in user’s message to bank
=sigbank(r)=(mbe)d=md(bed)=mdb
user
Create m=(amount, serial num)
mod n
This is bank’s signature on the actual coin m
To extract it, user divides bank’s signature on r
by his secret b. Bank has not learned m!
slide 7
“Cut-and-Choose” Verification
 User creates and blinds K coins, bank asks to open K-1 of
them (user doesn’t know in advance which ones)
Pick random i
r1=m1b1e … rk=mkbke
“amount=$10”
Give me all b1 … bk
except bi
b1 … bi-1 bi+1 … bk
user
Create k coins mi=(amount, serial num)
Public key=(n,e)
Extract m1 … mi-1 mi+1 … mk
and verify that they contain
the right amount
bank
Probability that user can cheat
without being detected is only 1/k
=sigbank(ri)=midbi
mod n
Coin mi will be used
slide 8
Double-Spending
Digital coins are easy to copy
• A digital coin is simply a bitstring with certain properties
Bank must keep track of spent coins to make sure
user does not spend the same coin twice
• Blinding is not a problem (why?)
Can’t prevent double-spending if bank is offline…
• User pays with same coin at many merchants; when
they try to deposit the coin, bank refuses all but one
– To prevent this, must involve bank in every transaction
… but can make sure that if a coin is doublespent, identity of cheater is revealed
slide 9
Preventing Double-Spending
Probability of this is 1-1/2n
merchant #2
If bib’i for at least one i, bank
can compute (Aliceri)  ri = “Alice”
and de-anonymize the cheater
ri if b’i=0
“Alice”ri if b’i=1
random
b’1…b’N
ri if b’i=0
“Alice”ri if b’i=1
Coin is double-spent
bank
1 or 0
ri if bi=0
“Alice”ri if bi=1
Cannot extract “Alice” from
this if coin is spent once
random b1…bN
Alice
Create N random numbers
r1, … rN for each coin
For each bi, send
ri if bi=0
“Alice”ri if bi=1
merchant #1
slide 10
Micropayment Schemes
Credit cards are impractical for payments < $10
• Newspaper articles, mobile downloads, etc.
• Processing one credit-card payment costs about 25c
Many (unsuccessful) micropayment schemes
• Millicent, PayWord, NetCard, iKP, PayTree, MicroMint
Key obstacle: implementation cost
• Customer acquisition, disputes, overspending, fraud
Idea: aggregate small payments to reduce perpayment processing cost
• Chaum’s digital coins are not good for aggregation
slide 11
Probabilistic Aggregation
User gives merchant a “lottery ticket” whose
expected value is equal to the payment amount
• Proposed independently by Rivest, Wheeler and others
• For example, instead of a 1-cent payment, give “lottery
ticket” that wins $10 with probability 1/1000
After a large number of payments, merchant’s
total winnings from lottery tickets will be
statistically close to the total amount of payments
• With 5000 tickets, merchant wins $50 on average
Only winning tickets need to be presented to bank
• Few tickets win, so processing cost greatly reduced
slide 12
Peppercoin
[Rivest and Micali]
On average, only 1 transaction out of 1000
wins and must be presented for payment
bank
Winning checks
“You owe me 1 cent”
user
siguser(“This check is worth $10 if the
three low-order digits of the
hash of your digital signature
on today’s date are 756”)
merchant
Probability of this is
approximately 1/1000
slide 13
Problem: Statistical Variations
Unlucky user may pay $20 for his
first two 1-cent transactions
• If both tickets happen to win
Payment scheme is user-fair if
user never has to pay more than
he would pay if all his payments
were non-probabilistic checks for
the exact amount
• I.e., as if user were writing 1-cent
checks instead of $10 lottery tickets
slide 14
Achieving User-Fairness
Assume that each payment is exactly 1 cent
User sequentially numbers his payments: 1, 2, …
When merchant submits a winning payment with
sequence number N, bank charges the user the
difference between this N and the previous
sequence number that has been paid
paid
paid
paid
User is charged 3 cents
• Severely punish users for reusing sequence numbers!
slide 15