\documentclass[times,10pt,twocolumn]{article}
\usepackage{latex8}
\usepackage{times}
\pagestyle{empty}
\newcommand{\xor}{\mbox{ {\sc XOR} }}
\begin{document}
\title{Remote Electronic Gambling}
\author{Chris Hall \qquad Bruce Schneier\\
Counterpane Systems\\
101 East Minnehaha Parkway\\
Minneapolis, MN 55419\\
{\tt \{hall,schneier\}@counterpane.com}}
\maketitle
\thispagestyle{empty}
\begin{abstract}
We examine the problem of putting a casino on the Internet. We discuss
fairly generating random bits and permutations for use in casino games,
protecting against player/player and player/dealer collusions, and
ensuring a secure audit trail that both the player and dealer can use
to ensure payment of debts. We conclude with a series of open problems.
\end{abstract}
\Section{Introduction}
Over the past several years commercial interest in the Internet has
grown. Naturally, casinos are eager to get online in order to try and
make money just like everyone else. One problem with electronic
casinos --- especially those housed in obscure countries with lax gambling
regulations --- is that they cannot necessarily be trusted: the players
have no way of being sure that the games are not rigged, that the
dealer is not cheating, or that the casino will pay out as promised.
This paper presents some solutions to these very real trust problems, and
can potentially be applied to any electronic commerce situtation where trust
is required.
Casinos exist to make money. People go to casinos in hopes of making
money. Therefore, two of the biggest issues in designing gambling
protocols are betting and debt payoff. In section \ref{bets_payoffs}
we briefly describe some of the issues involved with betting and paying off
debts, and in section \ref{gambling_credit} we discuss one way that money can
be represented in electronic casinos.
Most electronic gambling games boil down to making a prediction, generating
random numbers, and calculating a win/loss result. If the numbers are truly
random, then electronic games are mathematically indistinguishable from their
real-world counterparts. In section \ref{fair_random} we explore protocols
which allow two or more people to work together to choose a random number
which none can influence directly. A similar problem to choosing random
numbers is how two or more players can shuffle a deck of cards for a game; in
section \ref{fair_shuffle} we discuss protocols for card games, including how
to shuffle and deal cards.
When designing cryptographic protocols for gambling, several issues must be
kept in mind. While the ideal protocol will not allow any player to cheat,
this ideal can be difficult, if not impossible, to achieve. Therefore when
designing our protocols we focus more on making cheating detectible by
players and casinos. This means that we work to establish a good audit
trail so that someone who suspects that a player is cheating can use the
audit trail to see if they are right. However, this is not good enough.
Using the audit trail, the casino must be able demonstrate to a judge or
another authority figure that the first
player cheated (if that is indeed the case). In section \ref{hash_chain}
we discuss how the various protocols described in the previous sections are
tied together with hash chains in order to form an auditable chain to form
a body of evidence strong enough to convince a judge.
\SubSection{Notation}
The following notation is used throughout the paper.
\begin{description}
\item[$PK_A$] Denotes the public key of user $A$. This can
be a RSA \cite{RSA78} public key for encryption or digital signatures,
a DSS \cite{NIST94} public key, or a key for some other public key
scheme.
\item[$SK_A$] Denotes the secret key corresponding to the
public key $PK_A$. Again, this key can be used for either encryption
or digital signatures.
\item[$E_{PK}(M)$] Denotes the encryption of the plaintext message $M$
with the public encryption key $PK$.
\item[$D_{SK}(C)$] Denotes the decryption of the ciphertext message
$C$ with the secret decryption key $SK$.
\item[$E_K(M)$] Denotes the encryption of message $M$ with a symmetric
encryption algorithm, such as DES \cite{NBS77}, IDEA \cite{LMM91}, or
Blowfish \cite{Sch94}, and key $K$.
\item[$D_K(C)$] Denotes the decryption of the ciphertext message $C$
with a symmetric encryption algorithm and key $K$.
\item[$S_{SK}(M)$] Denotes the signature of message $M$ with secret
signature key $SK$.
\item[$H(M)$] Denotes the hash of the message $M$ with a cryptographic
hash function like SHA-1 \cite{NIST93} or RIPE-MD \cite{DBP96}.
\item[$A,B$] Denotes the concatenation of $A$ and $B$. This is commonly
used when describing messages.
\end{description}
Descriptions of these algorithm and methods can be found in
\cite{Sti95,Sch96,MvOV97}.
\Section{Bets and Payoffs}\label{bets_payoffs}
Two of the core issues in gambling are bets and enforcing their payoff. It
is important that one party (gambler or casino) cannot make a bet on another
person's behalf, and that a party can prove that someone else owes them money
as a result of a bet. This means that they must be able to prove not only
that they made a bet with the other party, but that the outcome of the bet was
in their favor. However, the other party should also have a way of proving
that they paid the debt once they do so.
There are several different betting situations that we have considered in
designing our protocols. For some games, like roulette, the bets are between
a gambler and the casino. When the gambler wins, the casino must pay their
debt and vice-versa. For other games, like poker, several players play
against each other and the casino merely arbitrates. Typically the casino
takes the pot that results from a game, keeps a percentage for itself (a
``rake''), and distributes the money among the winner(s). Hence, while
the gambling debts are really between players, they can all be transformed
into debts between the casino and the players. By doing this we can also
enforce player anonymity as the only iteraction two players have
occurs while they play the game, and in order to play a game it is not
necessary to know the identity of the other person. Once the game is over
the players interact with the casino in order to pay/collect their money.
The protocols in the following sections have been designed so that one
player can prove that another participated in a game and so that one player
can prove that the outcome of the game was in their favor if necessary,
i.e. they need to collect money after the protocol has ended. However, the
protocols presented do not enforce payoff. We are assuming that a trusted
third party exists for various services including settling payoff disputes.
\Section{Gambling Credit}\label{gambling_credit}
In order for a player to effectively gamble in a casino they must have
money. One simple way to represent money in a casino is in the form of
gambling credit. That is, each player has a credit with the casino. When
they lose a game the credit decreases appropriately and when they win a
game it increases. Once a gambler's credit with a casino reaches zero they
cannot gamble anymore unless they purchase more credit. On the other hand,
a gambler should have the option of leaving the casino and collecting the
appropriate amount of money represented by their credit (provided, of
course, that they are not in the middle of a game). The casino should be
careful that a player cannot participate in more than one game at a time.
Otherwise, the player may place bets on two different games for the full
value of their credit. If they lose both games, then they lose more money
than they have available to them in credit, and hence they owe the casino
money. It may be dificult (or impossible) for the casino to collect that
money.
There are many electronic commerce protocols \cite{CFN90,OO90,OO92,FY92,
Bra93a,Bra93b,MN93,CR93,Fer94,LMP94,Oka95,NM95,BGH+95,ST95,TMSW95,SK96},
and most can satisfy these requirements. However, as we mentioned
in the introduction, the casino cannot be trusted. Hence, player's cannot
necessarily trust that the casino will keep track of their gambling credit
accurately or pay the appropriate amount of money when they try and
collect. We have designed our protocols so that the player and casino work
together to create an auditable hash chain. The chain starts when the
gambler enters the casino and purchases some credit, and ends when the
gambler collects on their credit and leaves the casino. Every game that
the gambler participates in becomes part of the hash chain. The chain is
only valid once all games used to create it are accounted for, and hence
the casino and player can each prove exactly how much money exchanged
hands. That way the casino and player can each prove exactly how much
credit the player should have when they go to leave the casino. This
provides the sort of audit trail that we mentioned in the introduction
which either player or casino can use to catch a cheater.
We should point out that while the casino and the player work together
to create the hash chain, we have taken care to design the protocols so
that neither one can cheat the other. Thus, we have designed the hash
chain so that either player or casino can use a partially formed hash chain
to prove the other's actions up to the point of cheating. Since the
information contained in a valid, partially-formed hash chain binds both
the player and the casino, the longest partially-formed hash chain can be
used the event of a dispute. The person settling the dispute can then
decide whether one of the two parties cheated and how the dispute should be
resolved.
\Section{Fairness of Pure Luck Games}\label{fair_random}
Most casino games are solely games of chance: one or more players make a
bet on what the outcome of the game will be and the dealer (or machine)
commences with the game. This usually consists of rolling some dice,
spinning a wheel, or even spinning the dials of a slot machine.
In order for these kinds of games to be fair, the players should have some
sort of assurance that the dealer is not cheating, either by picking
``bad'' random numbers or lying about the outcome. If the players
and dealer agree on how the game should be played, they can work
together to generate a random number whose value will be used to
determine the outcome of the game.\footnote{Protocols which help the players
agree on the rules of the game are beyond the scope of this paper.
However, if should be noted that while a physical casino is limited by the
knowledge and training of the dealers, an electronic casino can easly play
with hundreds of different ``house rules'' simultaneously.} Once the outcome
is known, the players who won gain an appropriate credit with the casino, and
the players who lost lose an appropriate amount of credit.
Consider a two person protocol for generating a random number.
Suppose that Alice is the player and Bob is the dealer. There are several
protocols in which two people use a one-way hash function, $H$, to generate
random values. They commit to randomly chosen values and exchange them in
order to generate a random number which neither has an influence over. We
outline one protocol below among those found in \cite{Blu82,Bra88,Sch96}.
\begin{enumerate}
\item Alice generates a random number $R_0$ and sends $H(R_0)$ to Bob
(this protocol assumes that $R_0$ is large enough that Bob cannot do a
brute force search for $R_0$ given $H(R_0)$).
\item Bob generates $R_1$ and sends it to Alice.
\item Alice sends $R_0$ to Bob and computes
\[ R=R_0\xor{}R_1. \]
\item Bob verifies that the expected value of the hash matches the actual
value. If they do, he computes
\[ R=R_0\xor{}R_1. \]
\end{enumerate}
This protocol works, but there is a problem when applying it to electronic
gambling. Recall that the random value $R$ will be used to determine the
outcome of the game. If Alice determines that the computed value of $R$
will cause her to lose the game, then she can refuse to send $R_0$ to Bob
by cutting the connection. Unfortunately Bob has no way of proving that
Alice cut the connection maliciously and he also has no way of knowing
whether or not he won the game. He may suspect that he won, but he needs
more evidence if he wants to take Alice to court.
Nearly every protocol for generating random numbers in this fashion suffers
from the same weakness: Alice learns the outcome
before Bob. Because we want to apply this protocol to
gambling, one solution to this problem is to make it so that Alice does not
owe any money to Bob regardless of the outcome of the protocol. She can do
this by paying Bob as if she had lost. If she wins, then Bob not only owes
her the money he gambled, but he owes her the money she payed him before
carrying out the protocol. If she loses, then Alice cannot change the fact
that Bob gets to keep her money so she has no incentive to halt the protocol.
This protocol also applies to gambling games like slot machines. Alice pays
for a chance on the slot machine before she plays and tries to collect
her money if she wins. This is fairly similar to how real slot machines work
as you must put money or tokens into the machine before pulling the handle.
The protocols for paying and playing should be intertwined in order to prevent
a gambler from paying for one turn and ``reusing'' that turn with a
replay attack until they win.
One more modification needs to be made to this protocol before it can be
used. As stated, there is no way for Alice to prove that Bob actually
performed the protocol with her. Thus, if Alice wins the game and Bob
decides not to pay her, then Alice cannot prove to a trusted third party
that Bob owes her money. We can remedy this situation by using digital
signatures. The following protocol uses signatures and it has also been
generalized for situations in which two or more players wish to participate.
Alice is the dealer and Bob, Carol, and Dave are the three players.
\begin{enumerate}
\item Alice generates a random number, $R_A$, and sends everyone:
\[ M_0=H(R_A),S_{SK_A}(H(R_A)). \]
\item Bob generates a random number, $R_B$, and sends everyone:
\[ M_1=H(R_B),S_{SK_B}(M_0,H(R_B)). \]
\item Carol generates a random number, $R_C$, and sends everyone:
\[ M_2=H(R_C),S_{SK_C}(M_1,H(R_C)). \]
\item Dave generates a random number, $R_D$, and sends everyone:
\[ M_3=H(R_D),S_{SK_D}(M_2,H(R_D)). \]
\item Once Alice receives everyone else's hash, she sends everyone:
\[ M_4=R_A,S_{SK_A}(M_3,R_A). \]
\item Once Bob receives $M_4$, he sends everyone:
\[ M_5=R_B,S_{SK_B}(M_4,R_B).\]
\item Once Carol receives $M_5$, she sends everyone:
\[ M_6=R_C,S_{SK_C}(M_5,R_C). \]
\item Once Dave receives $M_6$, he sends everyone:
\[ M_7=R_D,S_{SK_D}(M_6,R_D). \]
\item Everyone computes \[ R=R_A\xor R_B\xor R_C\xor R_D. \]
\end{enumerate}
A comment on this protocol first. Each person must send their hashes
before sending their actual values. Otherwise the last person who
announces their random value could choose a random value which would allow
them to win.
There is a difficulty with this protocol. Suppose that Dave represents the
casino. Then the casino could try to collude with Carol. Once the protocol
reaches step 7, Carol could reveal her value $R_C$ to Dave without telling it
to everyone else. Then Dave would know the value of $R$ and thus be able to
predict the outcome of the protocol. Dave can request that Carol abort
the protocol if necessary. Since no one else knows that Dave and Carol are
colluding they cannot blame the aborted protocol on the casino. Similarly,
Dave could reveal $R_D$ to Carol and Carol could tell Dave to abort the
protocol. Hence, if we had the reverse situation in which Carol represents
the casino and Dave colludes with Carol, then Dave could abort the protocol
and shift the blame from the casino.
In general, we do not believe that it is possible to design a protocol for
more than two people which is safe from collusion. The problem we were
originally trying to solve was to decide what would happen if one player
aborts the protocol before completion because they know the outcome. If
two players are working with the casino to generate a random number, then
any way of deciding what to do in the event that one player aborts the
protocol is unfair to someone. If the rule is that the game is considered
void for the player, then two players could collude to abort the protocol
whenever one of them stands to lose a lot of money (Alice and Dave could be
the two players in the above protocol). The casino and a player could also
collude and abort the protocol whenever the other player stands to win big.
It may not be possible to rule that the game is still valid for the other
players because they may not know the outcome of the protocol and hence
won't be able to prove to a trusted third party that they actually won.
\Section{Fairness of Shuffling and Dealing}\label{fair_shuffle}
Some casino games are based on one or more decks of cards. Part of a card
game is shuffling and dealing the cards in a fair manner. As with the pure
chance games we described above, the player wants some way of being sure
that the dealer hasn't stacked the deck. There have been several protocols
described in the literature for playing poker \cite{SRA79,DM83,FM84,Yun85}.
These use public-key cryptography and require that players generate
new key pairs for each game they play, and this may be too
computation-intensive
for networked play. Additionally, most of these protocols
leak partial information about the cards themselves. Still other protocols
\cite{GM82,Cre86,Cre87} have no information leakage, but they are not at all
practical. They use zero-knowledge proofs; one implementation on three Sparc
workstations took eight hours to shuffle a deck \cite{Edw94}.
The following protocol works if the dealer is trusted.\footnote{
Recall that in some games the dealer wins a rake regardless of who wins the
card game. In these games the dealer can be trusted.} The dealer does not
know how the cards are shuffled before they are dealt; however, the dealer
does know what cards each player gets. Let Trent be the trusted dealer and
Alice and Bob be the two players. The first part of the protocol
effectively ``shuffles'' the cards:
\begin{enumerate}
\item Trent generates a permutation $P_T$ of the 52 cards and sends to
Alice and Bob:
\[ H(P_T),S_{SK_T}(H(P_T)). \]
Note, Trent (as well as Alice and Bob) should append a random salt to
the permutation before hashing it. He should not reveal the salt until
the end of the protocol. This will keep Alice or Bob from guessing
Trent's full permutation when only a few entries remain unknown (e.g.
when almost all the cards have been dealt).
\item Alice generates a permutation $P_A$ of the 52 cards and sends to
Trent and Bob:
\[ H(P_A),S_{SK_A}(H(P_T),H(P_A)). \]
\item Bob generates a permutation $P_B$ of the 52 cards and sends to Trent
and Alice:
\[ H(P_B),S_{SK_B}(H(P_T),H(P_B)). \]
\item Everyone verifies that the hashes they received are different than
the one they generated, i.e. that they all generated different
permutations. If they did not, then they redo the protocol.
\item Everyone agrees on the order to compose the permutations without
Trent's permutation (Alice before Bob or Bob before Alice). Assume for
discussion purposes that Alice's permutation will be applied before
Bob's.
\end{enumerate}
Although nobody knows how the cards are shuffled yet, the information
exists to determine the full arrangment of the cards. Whenever a player
needs a card the following protocol can be carried out. Assume that $n-1$
cards have been dealt already and Alice needs a card:
\begin{enumerate}
\item Alice determines $P_A[n]$, the $n$th entry of her permutation,
and sends to everyone:
\[ M_0=P_A[n],S_{SK_A}(H(P_A),H(P_B),H(P_T),n,P_A[n]). \]
Note, including the hash of her permutation as part of the signature
prevents someone else from replaying Alice's signature from another
iteration of the protocol.
\item Bob determines $P_B[P_A[n]]$, the $n$th entry of the permutation
formed by composing Alice's and his permutations, chooses a random salt
$R_1$, and sends to everyone:
\[ M_1=R_1,P_B[P_A[n]],S_{SK_B}(M_0,R_1,P_B[P_A[n]]). \]
\item Trent verifies Bob's signature and determines $C=P_T[P_B[P_A[n]]]$.
He then chooses a random salt $R_2$ and sends to Alice:
\[ E_{PK_A}(R_2,C,S_{SK_T}(M_1,R_2,C)). \]
\item Alice decrypts the message, verifies the signature, and adds the
card to her hand.
\end{enumerate}
After the game is over everyone reveals their permutations in order to make
sure nobody was cheating. This brings up a problem with this protocol (as
well as the next): everyone knows everyone else's hand when the game is
over. This is bad in games like poker when someone may not want to reveal
if they were bluffing.
The following protocol also works if the dealer is trusted. Let Trent be
the dealer and Alice and Bob be the two players. The first part of the
protocol effectively ``shuffles'' the cards:
\begin{enumerate}
\item Trent generates a permutation $P_T$ of the 52 cards and sends to
Alice and Bob:
\[ H(P_T),S_{SK_T}(H(P_T)). \]
\item Alice generates a permutation $P_A$ of the 52 cards and sends to Trent:
\[ E_{PK_T}(P_A,S_{SK_A}(H(P_T),P_A)). \]
\item Bob generates a permutation $P_B$ of the 52 cards and sends to Trent:
\[ E_{PK_T}(P_B,S_{SK_B}(H(P_T),P_B)). \]
\item Trent composes the three permutations to shuffle the cards. He
should compose them in an agreed upon order.
\end{enumerate}
Now whenever someone needs to be dealt a card they ask Trent for a card. He
pulls the next card off of the top of the deck, encrypts it, and sends it
to the player. He should really include a random salt $R$ so that any of
the other players cannot encrypt all 52 possible values for the card to see
which one the first player received. To summarize, suppose Alice needs a
card and $n$ cards have been dealt already. Then she carries out the
following protocol with Trent:
\begin{enumerate}
\item Alice picks a random number $R_0$, generates a request $M$ for a
card, and sends to Trent: \[ M_0=R_0,M,S_{SK_A}(R_0,M). \] Note, $M$
should contain an indentifier unique to the game and an indication that
this is the $n$th card to be dealt. That way replay attacks are
prevented.
\item Trent verifies the signature, picks the $n$th card out, generates a
random salt $R_1$, and sends to Alice:
\[ M_1=E_{PK_A}(R_1,M,C_n,S_{SK_T}(M_0,R_1,M,C_n)), \]
where $C_n$ denotes the $n$th card.
\item Alice decrypts the message, verifies the signature, and adds the
card to her hand.
\end{enumerate}
\Section{Chaining it all Together}\label{hash_chain}
Many gambling games require actions like placing bets and asking for more
cards. By using hash chains \cite{HS91,KS97} each event can linked into
the game. In
order for the hash chain to verify correctly, every event must be accounted
for. Hence it is impossible for one player to prove that the game was in
their favor unless they show that everything which happened in the game
lead to the supposed outcome.
If a dispute arises in which the player claims that the casino did not give
them all of their money, then the player must be able to prove this claim
to a third party. The player will have to prove that the amount of credit
that they purchased along with their net winnings is unequal to what the
casino paid them. This means that they will have to prove the outcome of
every game, including the ones they lost. On the other hand, the casino
should be able to prove the amount of money the player initially had, the
net winnings of the casino, and how much money they finally payed the player.
As we said, we have designed our protocols to help
the winner of a game prove that they won. We also stated that protocols
for helping one player to prove that they paid their debt to another are
beyond the scope of this paper. The last supporting element we need is
proof that the player actually participated in all of the games that they
claim and that they didn't participate in any other games (otherwise a
player could try and claim that the casino owes them more money by
conveniently ``forgetting'' a game in which they lost money). One way to
implement this protocol is to ensure that the token purchasing protocol,
every protocol used in the games, and the final cash-in protocol are linked
in an unbreakable manner. This can be done using hash chains.
In \cite{SK97}, Schneier and Kelsey describe a solution to the hash
chaining problem. Each signature includes a hash of the previous message
in addition to a hash of the message being signed. Hence each signature in
the chain forms a link with the previous signature which cannot be changed,
even if the signing key is later broken. This means that all actions in
the casino are tied together by the signatures generated by the gamblers
and the casinos. Therefore, all important events in the games (which are
really all events) require a signature from the player stating them.
\Section{Conclusion and Open Problems}
We have explored several issues that are important in online gambling. In
addition we have drawn out several protocols which are useful in
implementing some of the classic casino games. These include generating
random numbers and shuffling a deck of cards. We discussed some of the
issues involved in betting and payoffs; however, a full-blown dicussion is
beyond the scope of this paper. Finally, we considered how to make the
games non-refutable and briefly considered anonymity.
The protocols that we presented are not perfect. There are some open
problems which must be solved before we can improve on the protocols.
These are the problems as we see them:
\begin{enumerate}
\item Is it possible to design a general $N$-person ($N>2$), asynchronous
coin flipping protocol in which each person contributes to the outcome
of the protocol and is immune to player collusion? We briefly
addressed this issue when discussing $N$-person protocols for generating
random numbers. However, our protocols are not immune to the effects
of player collusion (as we pointed out). We believe that we have an
informal proof that such a protocol does not exist, but to the best of
our knowledge no formal proof or counterexample exists.
\item Can $N$ people work together to shuffle a deck of cards so that no
person knows the arrangment of the deck and that each player does not
have to generate a new public-key key pair for the protocol? As we
stated previously, the simplest protocols for shuffling a deck of cards
require each player to create a new key pair for each iteration of the
protocol. For online gambling systems this is impractical.
\item Is there a card shuffling protocol that works even if the dealer is
not trusted? There are theoretical solutions---secure multi-party
protocols---but are there any practical ones?
\end{enumerate}
\Section{Acknowledgments}
The authors would like to thank John Kelsey, James Jorasch, and Jay
Walker for their helpful comments.
\begin{thebibliography}{99}
\setlength{\itemsep}{-1ex}\small
\bibitem{BGH+95} M. Bellare, J.A. Garay, R. Hauser, A. Herzberg,
H. Krawczyk, M. Steiner, G. Tsudik, and M. Waidner, ``iKP - A Family of
Secure Electronic Payment Protocols'', {\it The First USENIX Workshop on
Electronic Commerce,} USENIX Association, 1995, pp. 89--106.
\bibitem{Blu82} M. Blum, ``Coin Flipping by Telephone: A Protocol
for Solving Impossible Problems,'' {\it Proceedings of the 24th IEEE
Computer Conference (CompCon)}, 1982, pp. 133--137.
\bibitem{Bra93a} S. Brands, ``Untraceable Off-line Cash in Wallets
with Observers,'' {\it Advances in Cryptology---CRYPTO '93 Proceedings,}
Springer-Verlag, 1994, pp. 302--318.
\bibitem{Bra93b} S. Brands, ``An Efficient Off-line Electronic
Cash Systems Based on the Representation Problem,'' C.W.I. Technical Report
CS-R9323, 1993.
\bibitem{Bra88} G. Brassard, {\it Modern Cryptology: A Tutorial},
Lecture Notes in Computer Science 325, Springer-Verlag, 1988.
\bibitem{CFN90} D. Chaum, A. Fiat and M. Naor, ``Untraceable
Electronic Cash,'' {\it Advances in Cryptology---CRYPTO '88 Proceedings},
Springer-Verlag, 1990, pp. 319--327.
\bibitem{CR93} CitiBank and S. S. Rosen, ``Electronic-Monetary
System,'' International Publication Number WO 93/10503; May 27 1993.
\bibitem{Cre86} C. Crepeau, ``A Secure Poker Protocol that Minimizes
the Effect of Player Coalitions,'' {\it Advances in Cryptology---CRYPTO '85
Proceedings}, Springer-Verlag, 1986, pp. 73--86.
\bibitem{Cre87} C. Crepeau, ``A Zero-Knowledge Poker Protocol that
Achieves Confidentiality of the Players' Strategy, or How to Achieve an
Electronic Poker Face,'' {\it Advances in Cryptology---CRYPTO '86
Proceedings}, Springer-Verlag, 1987, pp. 239--247.
\bibitem{DM83} R. DeMillo and M. Merritt, ``Protocols for Data
Security,'' {\it Computer}, v. 16, n. 2, Feb. 1983, pp. 39--50.
\bibitem{DBP96} H. Dobbertin, A. Booselaers, and B. Preneel,
``RIPEMD-160:
A Strengthened Version of RIEPMD,'' {\it Fast Sofrware Encryption, Third
International Workshop,} Springer-Verlag, 1996, pp. 71--82.
\bibitem{Edw94} J. Edwards, ``Implementing Electronic Poker: A
Practical Exercise in Zero-Knowledge Interactive Proofs,'' Master's
thesis, Department of Computer Science, University of Kentucky, 1994.
\bibitem{Fer94} N. Ferguson, ``Extensions of Single-Term Coins,''
{\it Advances in Cryptology -- Proceedings on CRYPTO '93,} Springer-Verlag,
1994, pp. 292--301.
\bibitem{FM84} S. Fortune and M. Merritt, ``Poker Protocols,'' {\it
Advances in Cryptology: Proceedings of CRYPTO 84}, Springer-Verlag, 1985,
pp. 454--464.
\bibitem{FY92} M. Franklin and M. Yung, ``Towards Provably Secure
Efficient Electronic Cash,'' Columbia Univ. Dept of C.S. TR CUCS-018-92,
April 24, 1992.
\bibitem{GM82} S. Goldwasser and S. Micali, ``Probabilistic
Encryption and How to Play Mental Poker Keeping Secret All Partial
Information,'' {\it Proceedings of the 14th ACM Symposium on the Theory
of Computing}, 1982, pp. 270--299.
\bibitem{HS91} S. Haber, W.S. Stornetta, ``How to Time Stamp a
Digital Document,'' in {\it Advances in Cryptology--Crypto '90},
Springer-Verlag, 1991.
\bibitem{KS97} J. Kelsey and B. Schneier, ``Cryptographic Support for
Secure Logs on Untrusted Machines,'' in preparation.
\bibitem{LMM91} X. Lai, J. Massey, and S. Murphy, ``Markov Ciphers
and Differential Cryptanalysis,'' {\it Advances in Cryptology---CRYPTO '91},
Springer-Verlag, 1991, pp. 17--38.
\bibitem{LMP94} S. H. Low, N. F. Maxemchuk, and S. Paul, ``Anonymous
Credit Cards,'' {\it The Second ACM Conference on Computer and
Communications Security,} ACM Press, 1994, pp. 108--117.
\bibitem{MN93} G. Medvinsky and B. C. Neuman, ``Netcash: A Design for
Practical Electronic Currency on the Internet,'' {\it The First ACM
Conference on Computer and Communications Security,} ACM Press, 1993,
pp. 102--106.
\bibitem{MvOV97} A.J. Menezes, P.C. van Oorschot, S.A. Vanstone,
{\it Handbook of Applied Cryptography}, CRC Press, 1997.
\bibitem{NBS77} National Bureau of Standards, NBS FIPS PUB 46,
``Data Encryption Standard,'' National Bureau of Standards, U.S. Department
of Commerce, Jan 1977.
\bibitem{NIST93} National Institute of Standards and Technology,
NIST FIPS PUB 180, ``Secure Hash Standard,'' U.S. Department of Commerce,
May 1993.
\bibitem{NIST94} National Institute of Standards and Technologies,
NIST FIPS PUB 186, ``Digital Signature Standard,'' U.S. Department of Commerce,
May 1994.
\bibitem{NM95} B. C. Neuman and G. Medvinsky, ``Requirements for
Network Payment: The NetCheque${}^{TM}$ Perspective,'' Compcon '95, pp. 32-36
\bibitem{Oka95} T Okamoto, ``An Efficient Divisible Electronic Cash
Scheme,'' {\it Advances in Cryptology---Crypto '95 Proceedings},
Springer-Verlag, 1995, pp. 438--451.
\bibitem{OO90} T. Okamoto and K. Ohta, ``Disposable Zero-Knowledge
Authentication and Their Applications to Untraceable Electronic Cash,''
{\it Advances in Cryptology---CRYPTO '89 Proceedings}, Springer-Verlag,
1990, pp. 481--496
\bibitem{OO92} T. Okamoto and K. Ohta, ``Universal Electronic Cash,''
{\it Advances in Cryptology---CRYPTO '91 Proceedings}, Springer-Verlag,
1992, pp. 324--337.
\bibitem{RSA78} R. Rivest, A. Shamir, and L. Adleman, ``A
Method for Obtaining Digital Signatures and Public-Key Cryptosystems,''
{\it Communications of the ACM}, v. 21, n. 2, Feb 1978, pp. 120--126.
\bibitem{Sch94} B. Schneier, ``Description of a New
Variable-Length Key, 64-Bit Block Cipher (Blowfish),'' {\it Fast Software
Encryption, Cambridge Security Workshop Proceedings}, Springer-Verlag, 1994,
pp. 191-204.
\bibitem{Sch96} B. Schneier, {\it Applied Cryptography, Second
Edition,} John Wiley \& Sons, 1996.
\bibitem{SK96} B. Schneier and J. Kelsey, ``A Peer-to-Peer
Metering System,'' {\it The Second USENIX Workshop on Electronic
Commerce Proceedings,} USENIX Association, 1996, pp. 279--286.
\bibitem{SK97} B. Schneier and J. Kelsey, ``Automatic Event-Stream
Notarization Using Digital Signatures,'' {\it Security Protocols: International
Workshop, Cambridge, United Kingdom, April 1996 Proceedings}, Springer-Verlag,
1997, pp. 155--170.
\bibitem{SRA79} A. Shamir, R. Rivest, and L. Adleman, ``Mental Poker,''
in {\it Mathematical Gardner}, D.E. Klarner, ed., Wadsworth International,
1981, pp. 37--43.
\bibitem{ST95} M. Sirbu and J. D. Tygar, ``NetBill: An Internet
Commerce System Optimized for Network Delivered Services,'' Compcon '95,
pp. 20--25.
\bibitem{Sti95} D.R. Stinson, {\it Cryptography: Theory and
Practice}, CRC Press, 1995.
\bibitem{TMSW95} J. M. Tenenbaum, C. Medich, A. M. Schiffman,
and W. T. Wong, ``CommerceNet: Spontaneous Electronic Commerce on the
Internet,'' Compcon '95, pp. 38--43.
\bibitem{Yun85} M. Yung, ``Cryptoprotocols: Subscriptions to a
Public Key, the Secret Blocking, and the Multi-Player Mental Poker
Game,'' {\it Advances in Cryptology: Proceedings of CRYPTO 84},
Springer-Verlag, 1985, pp. 439--453.
\end{thebibliography}
\end{document}