Towson University
Department of Computer and Information Sciences
Digital Cash
Applied Cryptography
Nathan Bible, Brian Haar, Hui Liu
December 13, 2010
COSC 645 - Dr. Marius Zimand
Nathan Bible, Brian Haar, Hui Liu
Digital Cash Project
COSC 645: Applied Cryptography
Date: Dec 13, 2010
INTRODUCTION
People often use their credit or debit cards to make purchases throughout their
daily lives. However, many of these daily transactions are sensitive (e.g. illegal or
immoral) and require the anonymity of cash. Despite many advances in modern payment
systems such as credit cards, PayPal, and even Obopay, none of these systems offer the
anonymity of cash. Carrying around a large amount of paper money has many
drawbacks too, most notably it is subjective to theft. Because of all of these reasons,
there is a need for a digital cash protocol as developed by Schneier.[1] In this paper, we
will provide an overview of this protocol and describe our implementation of it.
This digital cash protocol provides a method for customer Alice to purchase an
electronic money order anonymously from a bank, and then spend it anonymously with
merchant Bob, who can then deposit it at the bank. Each party involved has no identity
information about the others in terms of the actual flow of money. One key to this
protocol is to ensure that neither Alice nor Bob try to cheat the bank by copying their
digital cash or claiming a greater value than in reality. Because anonymity is the ultimate
goal of this digital cash protocol, it is important to note that there are many economic and
legal concerns about possible real world implementations.[2][3]
Many additional or sub-protocols are needed to implement this digital cash
protocol including secret splitting, bit commitment, blind signatures, RSA, and MD5 to
name a few.
The secret splitting algorithm was borrowed from Tewari et al.[4] It divides the
customer identity string into two parts that alone have no meaning, but provide the
original string when the exclusive-or operation is applied to the two halves. The
commitment of these halves is described by Noir[5] and involves two stages, a commit
stage and a revealing stage. The commit stage produces some information about the split
identity strings that can be given to another party, while the revealing stage gives the
actual split identity strings to the other party. The blind signature algorithm was
originally developed by Chaum[6] requires a private signing function and publicly known
inverse, similar to RSA.
This final version of this project was implemented using an Apache HTTP Server
using PHP5 “Hypertext Preprocessor”, and Oracle Express Edition for the database and
will be available online at http://goohoo.dnsalias.com/digicash/ for several days
following the completion of this project. All source code, including the Oracle table
generation script as well as this document, is hosted on Google Code and is accessible by
web or SVN at: http://digital-cash.googlecode.com/svn/trunk/
Page: 2 of 6
Nathan Bible, Brian Haar, Hui Liu
Digital Cash Project
COSC 645: Applied Cryptography
Date: Dec 13, 2010
PROJECT
For our implementation of digital cash, we have broken the process down into
several (some Required, some Optional) steps and sub-steps with required protocols as
follows:

1R
o Alice prepares n money orders (number, value, uniqueness string)
 The format of the money order as strings, which is used for most of
the necessary functions, is the following values in this order
concatenated by a colon: uniqueness string, value, committed ID
string Secret Left1, committed ID string Secret Right1, … ,
committed ID string Secret Leftn, committed ID string Secret Rightn
o Alice commits n different Left and Right half secretly split ID strings on
each money order
 The ID string contains Alice’s first name, last name, and account
number concatenated with a colon.
 The ID string is split by choosing a random number from 0-127,
and XORing that random number with the ASCII value for each
character in the ID string, the random number and the result from
the XOR respectively are the secret “left” and “right” keys this is
done n2 times, once for each ID string in each money order.
 Each secret split half is individually committed by hashing it by an
MD5 function.
o Alice blind all n money orders
 A very large secret random number r is generated, a different one
for each money order.
 Alice calculates the md5 hash h for each money order.
 Alice calculates re * h (mod n), the RSA encryption function using
the bank’s public key e.

2R
o Alice gives the blind money orders to the bank
o Bank chooses random number z between 1 and n (number of money orders)
and asks the customer to un-blind all money orders except for this one.
o Alice un-blinds [1,z-1][z+1,n] money orders by sending the bank the
random r for each money order, the string of each money order, the format
of which is explained above, and both halves of each secretly split ID
string.
o Bank verifies all n-1 un-blinded money orders are well formed
 Bank calculates the md5 hashes itself.
 Bank verifies un-blinded money orders and blinded money orders
match.
 Bank verifies that all amounts of n-1 un-blinded money orders are
the same.
 Bank verifies that all uniqueness strings of n-1 money orders are
unique
 Bank verifies all the committed ID string half hashes are valid, and
all the secretly split halves form Alice’s ID string.
Page: 3 of 6
Nathan Bible, Brian Haar, Hui Liu
Digital Cash Project
COSC 645: Applied Cryptography
Date: Dec 13, 2010
o If everything is valid, the bank signs the one remaining blinded money
order. If the value for one of them is different, then Alice probably tried
to cheat.
 The bank signs the only remaining money order it didn’t unblind
using its RSA private key, calculating following:
(re * h)d (mod n) = r * hd (mod n)
 The bank deducts the value of the money order from Alice’s
account and pass blinded signature to Alice.
o Alice receives signed money order and her account is debited, or is caught
and goes to jail.
 Alice multiplies the returned value from the bank by the inverse of
her secret r, r-1, for that money order to get the bank-signed hash of
the money order, hd (mod n).

3O
o Alice chooses to copy her bank signed money order and spend it at two
merchants, continued at 4RC.


4R
o Alice wants to make a purchase and gives the signed money order and the
bank’s signature, hd, to Bob.
o Bob verifies the signature of the money order by calculating the MD5 hash
of the money order, and verifies the bank-signed signature by calculating
(hd)e = h. If the two values are equal, then the hash is valid.
o Bob chooses an n-bit selector string
o Alice reveals the either the L or R half of each ID string of the money
order according to Bob’s selector string.
o Bob calculates the MD5 hashes of each returned ID string half and
compares it to the committed ID string hashes.
o If everything is valid, Bob accepts the money order as payment.
4RC
o Alice wants to cheat and tries to spend the money order a second time with
another merchant. She gives the signed money order and the bank’s
signature, hd, to the second merchant.
o The second merchant, like the first, verifies the signature of the money
order by calculating the MD5 hash of the money order, and verifies the
bank-signed signature by calculating (hd)e = h. If the two values are equal,
then the hash is valid.
o The second merchant then chooses an n-bit selector string. There is only a
probability of n2 that both merchants select the same selector string. The
process proceeds as if he chose a different one from the first.
o Alice reveals the either the L or R half of each ID string of the money
order according to the new selector string.
o The second merchant accepts calculates the MD5 hashes of each returned
ID string half and compares it to the committed ID string hashes.
o If everything is valid, Bob accepts the money order as payment.
o The second merchant goes to the bank to deposit the money order. The
results are explained in part 6R.
Page: 4 of 6
Nathan Bible, Brian Haar, Hui Liu
Digital Cash Project

COSC 645: Applied Cryptography
Date: Dec 13, 2010
5O
o Bob chooses to copy the money order with revealed ID string halves. The
result is explained in part 6R.

6R
o Bob or the second merchant goes to the bank to deposit the money order.
He gives the money order, the signature, the selector string, and the
revealed ID string halves to the Bank.
 The Bank verifies the signature of the money order by calculating
the MD5 hash of the money order, and verifies the bank-signed
signature by calculating (hd)e = h. If the two values are equal, then
the signature is valid.
 Check the uniqueness string on the money order with uniqueness
strings of previously paid money orders (from database).
 If the uniqueness string is not found in the database.
 Then the money order has not been seen before and is
accepted, and Bob’s account is credited the value.
 The bank records all the information about the money order,
including Bob’s selector string and the revealed ID string
halves.

If the same uniqueness strings is found, this money order has been
used before. The bank refuses to accept the money order.
 The bank compares the identity strings on the money order
with the ones stored in the database.
o If they are the same, then the depositor (Bob)
cheated by copying the ID strings halves, because
he cannot recover the input value from one of the
other hashes. If he were to give fake values, then
the whole money order signature would be
invalidated.
o If they are not the same for any ID string number,
then the bank takes the two halves for that number,
XORs them together, and the result will be Alice’s
ID String. Again, this is her first name, last name,
and account number. Alice cheated by spending the
money order twice. She can’t control what the
selector string is the merchant gives her, so she had
to reveal the secret to her ID string, and thus
breaching her anonymity.
Page: 5 of 6
Nathan Bible, Brian Haar, Hui Liu
Digital Cash Project
COSC 645: Applied Cryptography
Date: Dec 13, 2010
We chose to use PHP because it was the simplest way and most logical way to
implement the views of many different people, who may not ever be in the same place.
This system requires input by the customer, the bank, and multiple merchants, and a web
interface was the most intuitive to implement. Each person can have a series of web
pages devoted entirely to their perspective of the interaction. Furthermore, this system
could be actively implemented in a distributed system simply by updating some form urls,
a process taking about five minutes, and some database credentials, which would be
another five minutes. As such, the bank’s pages could be hosted on a server in one place,
and each of the merchants’ pages could be hosted on a server someplace else. This
makes our system very versatile.
For the RSA implementation, first a pure PHP script was used for generating RSA
keys. This script timed out on every attempt to generate new keys. Although it only
needed to be run once, it would be preferable to have a faster script. A Java program
utilizing the javax.security module was used for generating RSA keys, and was
seamlessly implemented with the PHP script (a demo is available under rsa_demo.php).
This was only used for key generation. We programmed all actual RSA functions
ourselves in PHP to use these keys.
As for the format, we chose use a series of “click-throughs” to show all of the
data as it is processed. This provides each party with all of the details they use in the
interaction, but requires only minimal input by any party. This has the advantage of each
party having the ability, if they choose, to manually check and verify every item at every
step, while not burdening them with having to provide anything.
RESULTS
Our project fully implements the anonymous digital cash protocol as described
above. It successfully protects the anonymity of the honest customer while protecting the
bank from the possibility of either a dishonest customer or a dishonest merchant by
identifying only the offending party.
REFERENCES
[1] B. Schneier. Applied Cryptography. John Wiley & Sons, 1996, New York, pp.
139-147.
[2] T. Tanaka. Possible Economic Consequences of Digital Cash. First Monday,
Volume 1, Number 2.
[3] A. Foomkin. Flood Control on the Information Ocean: Living With Anonymity,
Digital Cash, and Distributed Databases. 15 U. Pittsburgh Journal of Law and
Commerce 395 (1996).
[4] H. Tewari, D. O’Mahony, M. Peirce. Reusable Off-Line Electronic Cash Using
Secret Splitting. Technical report, Trinity College, 1998
[5] M. Naor. Bit Commitment Using Pseudorandomness. Advances in Cryptology Crypto 89. Lecture Notes in Computer Science, Vol. 435, Springer-Verlag, New
York, 1990, pp. 128-137.
[6] D. Chaum. Blind Signatures for Untraceable Payments. In .-1dz:ances in
Cryptology – proceedings of CRYPT0 83, 19S.1.
APPENDIX
Database DDLsql
PHP code
Page: 6 of 6