

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The implementation of a digital cash system using blind signatures to ensure anonymity and prevent double spending. The protocol involves three parties: the customer, the merchant, and the bank. The problems with a simple implementation and proposes a solution using blind signatures and one-way functions. It also discusses an offline ecash scheme to detect double spending without revealing the user's identity.
Typology: Study notes
1 / 3
This page cannot be seen from the preview
Don't miss anything!


In this lecture we will explore some issues in implementing a digital form of cash - ecash. We normally think of cash as paper money or coins issued by the treasury or a central bank. Can the assurances normally assumed for cash be made to carry over to the digital domain in the form of a sequence of bits? To explore some of the issues that arise in this context, let us consider a protocol involving three players: the customer, the merchant and the bank. The outline of the protocol we would like to implement is as follows:
The customer, Alice, interacts with the bank to withdraw some cash. She then interacts with the merchant, exchanging the cash for some goods. The merchant, Bob, then interacts with the bank to deposit the cash in his account.
A first attempt at implementing this protocol might look like this:
There are several problems with this protocol.
Blind Signatures:
One of the key building blocks to achieve anonymity is a blind signature. Recall that RSA signatures require the signer to compute md^ mod N , where ( d , N ) is the private key and ( e , N ) is the public key.
A blind RSA signature is carried out as follows:
The point is that t = sd^ = ( rem ) d^ = rmd^ mod N. A blind signature allows Alice to obtain Bob’s signature on a message of her choice, without Bob having any idea what the message being signed is.
Proposal 1:
Alice and the bank will use blind signatures to collectively create a $1 bill signed by the bank, but one which the bank will not recognize as coming from Alice.
In this scheme, a valid $1 bill is a pair ( x , y ) where y = f ( x ) d^ mod N. Here f () is a one-way function (ideally a one-way hash function). ( e , N ) is the bank’s public key and ( d , N ) is the private key.
The main feature of this scheme is that the bank cannot connect the bill ( x , y ) with Alice, since the blind signature was performed on a perfectly random string s.
The reason for the one-way function f () is to prevent forging. For example if instead a valid $1 bill were ( x , y ) where y = xd^ mod N , then Alice could forge a bill by first picking y mod N and then computing x = ye^ mod N. Instead, in the protocol presented above, y = f ( x ) d^ , and forging in this way would require Alice to invert the one-way function. This is because when Alice selects y at random and encrypts it, she obtains f ( x ), instead of x which she needs to successfully forge.
One way to create ecash with several denominations is for the bank to use different RSA keys to create bills of different denominations. There is also an elegant way for the bank to achieve this while using the same composite N , but different encryption exponents e for different denominations: e.g. e = 3 for nickels, e = 5 for dimes, e = 7 for quarters, and e = 11 for dollar bills. One subtle point is that choosing e = 9 for a dollar bill would be a mistake. This is because under this scheme ( x , y ) is a valid dollar bill whenever y^9 = f ( x ) mod N. Now, ( x , z = y^3 ) is a valid nickel, since z^3 = y^9 = f ( x ) mod N. Thus choosing e = 0 would allow Alice to forge an extra nickel for every dollar she withdraws from the bank. Choosing the encryption exponents to be prime numbers gets around this potential problem.
One issue with this ecash scheme is that the bank has to be online at all times to identify bills, and the merchant, Bob, must cash the bill immediately, in case Alice tries to double spend. These days this is not considered a major problem, but for completeness we describe an offline scheme below.
”Offline ecash:”
The basic idea of this scheme is that instead of preventing double spending, it enables the bank to detect it. If the user does not double spend, the bank does not learn her identity. If the user double spends, the bank can compute her identity, and take suitable action.