sync

1 files changed, 43 insertions, 35 deletions

diff --git a/games/games.tex b/games/games.tex
index 1da4672..6d19216 100644
--- a/games/games.tex
+++ b/games/games.tex
@@ -417,7 +417,7 @@ allowing them to talk to themselves does not make sense / does not give them mor
 \begin{mdframed}
   Fairness is a very overloaded term in crypto, can we come up with something better?
   It's already used for (a) protocols where either none or all parties obtain a result and
-  (b) as fair e-cash, which is e-cash with selective tracability for e.g. law enforcement.
+  (b) as fair e-cash, which is e-cash with selective tracability/deanonymization for e.g. law enforcement.
 \end{mdframed}
 
 Intuitively, the adversary wins if a non-corrupted user is unable to obtain a
@@ -426,24 +426,22 @@ example, when the merchant is able to spend a coin in a way not anticipated by
 the customer, keep the coin in a state that neither gives the customer a
 receipt nor allows the customer to refresh it.
 
-In practice, this
+In practice, this property is necessary to guarantee that aborted or partially completed
+payments do not result in the customer losing money or their anonymity.
 
-The game also covers the case where the exchange pretends the customer did a
-bad refresh.
-
-We restrict to a single denomination here for simplicity, but
-the reader may replace $C_n$ by the leaf coins in the refresh tree.
+The game also covers the case where a malicious exchange pretends the customer
+did a dishonest refresh (in instantiations that allow dishonest refreshes).
 
 Let \oraSet{Fair} stand for access to the oracles
  \ora{AddClient}, \ora{WithdrawAsExchange}, \ora{Spend},
  \ora{RefreshAsExchange}, \ora{Share}, \ora{CorruptClient}, \ora{Deposit}.
 
 \bigskip
-\noindent $\mathit{Exp}_{\cal A}^{fair}(1^\lambda, \kappa)$:
+\noindent $\mathit{Exp}_{\cal A}^{fair}(1^\lambda, 1^\kappa)$:
 \vspace{-0.5\topsep}
 \begin{enumerate}
   \setlength\itemsep{0em}
-  \item $(skE, pkE) \leftarrow \mathrm{EKeygen}()$ 
+  \item $(skE, pkE) \leftarrow \mathrm{EKeygen}(1^\lambda, 1^\kappa, M)$ 
   \item $C_0 \leftarrow {\cal A}^{\oraSet{Fair}}(pkExchange)$
   \item If $C_0$ is not a coin public key, return 0.  Let $U$ be the user that has $C_0$ in their wallet.  If no such $U$ exists, return 0.
   \item Let $C_0, \dots, C_n$ be the coins reachable via \algo{Link} from $C_0$, and let $A[C]$ be the value
@@ -455,22 +453,22 @@ Let \oraSet{Fair} stand for access to the oracles
       \item If $R$ indicates an error response containing a double spending proof with contract $h$ and $h \notin contractHashes[U]$, return 1.
       \item If $R$ indicates existing refreshes (failed or succeeded) into coins of total value $w$, return 1 if $w > A[C]$.
     \end{enumerate}
-  \item Return 0
+  \item Return 0 (if this step is reached without an earlier return)
 \end{enumerate}
 
+\begin{mdframed}
+  The game is written in a way that does not refer to failed refreshes explicitly.
+\end{mdframed}
+
 
 \subsection{Unforgability} % Exculpability?
 
-Intuitively, adversarial customers win if they can forge more
- valid coins than they withdraw.
-
-We again restrict to a single denomination for simplicity, but
-the reader could reformulate the game in terms of values instead of
- the number of coins.
+Intuitively, adversarial customers win if they can forge more valid coins than
+they withdraw.
 
 Let \oraSet{Forge} stand for access to the oracles
  \ora{AddClient}, \ora{WithdrawAsExchange}, \ora{Spend},
- \ora{RefreshAsExchange}, \ora{Share}, \ora{CorruptClient}.  ???
+ \ora{RefreshAsExchange}, \ora{Share}, \ora{CorruptClient}.
 
 \bigskip
 \noindent $\mathit{Exp}_{\cal A}^{forge}(1^\lambda, \kappa)$:
@@ -479,24 +477,24 @@ Let \oraSet{Forge} stand for access to the oracles
   \setlength\itemsep{0em}
   \item $(skE, pkE) \leftarrow \mathrm{EKeygen}()$ 
   \item $(C_0, \dots, C_\ell) \leftarrow \mathcal{A}^{\oraSet{Forge}}(pkExchange)$
-  \item Our adversary wins if they made at most $\ell$ withdrawals
-    but $C_0, \dots, C_\ell$ are all distinct valid unspent unrefreshed coins.
+  \item Our adversary wins if the sum of the unspend value of valid coins in $C_0 \dots, C_\ell$
+    exceeds the amount withdrawn by corrupted peers.
 \end{enumerate}
 
 
 \subsection{Income Transparency}
 
-Intuitively, the adversary wins if money is in exclusive control
-of corrupted clients, but the exchange has no record of withdrawal
-or spending for it.  In this, we exploit that our adversary cannot delete 
-from non-corrupted customer's wallets, even though they can direct 
-protocol interactions by non-corrupted customers.
+Intuitively, the adversary wins if money is in exclusive control of corrupted
+clients, but the exchange has no record of withdrawal or spending for it.  This
+of course presumes that the adversary cannot delete from non-corrupted
+customer's wallets, even though they can use oracles to force protocol
+interactions of non-corrupted customers.
 
-We again restrict to a single denomination for simplicity, but
-the reader could reformulate the game in terms of values instead of
- the number of coins.
-We note that adapting the security proof below requires replacing
- the proof's special value $R_C$ by a suitably defined edge partial anti-chain.
+For practical e-cash systems, Income Transparency disincentivizes the emergence
+of ``black markets'' among mutually distrusting users, where currency
+circulates without the transactions being visible.  The Link protocol
+introduces the threat of losing coins (even after having refreshed them) that
+were received without involvement of the exchange.
 
 Let \oraSet{Income} stand for access to the oracles
  \ora{AddClient}, \ora{WithdrawAsExchange}, \ora{Spend},
@@ -511,7 +509,7 @@ Let \oraSet{Income} stand for access to the oracles
   \item $(C_1, \dots, C_\ell) \leftarrow \mathcal{A}^{\oraSet{Income}}(pkExchange)$ \\
           \item Augment the wallets of all non-corrupted users with their
     transitive closure using the \algo{Link} protocol.
-    Mark all coins in wallets of non-corrupted users as spent.
+    Mark all coins in wallets of non-corrupted users as spent (with \algo{Deposit}).
   \item Let $L$ be the sum of unspent value for valid coins in $C_1, \dots\, C_\ell$, after
     accounting for the previous spending step.
   \item Let $w'$ be the number of coins withdrawn by corrupted clients.
@@ -540,13 +538,23 @@ adversary wins the game or not.
   not necessarily exist for other instantiations (and the game was more complicated with it).
 \end{mdframed}
 
-\subsection{Others?}
-Let adversary distinguish between freshly withdrawn coin and coin obtained via refresh protocol.  Why?
+\subsection{Others}
+
+\subsubsection{Exculpability}
+Exculpability is not necessary, since coins are spent on-line with the exchange.
+In practice, even offline e-cash systems that provide exculpability are often undesireable, 
+since hardware failures can result in unintentional double spending.
 
-Camenisch-style fair exchange and endorsements.  Should not be too much work, games are already
-given in literature.
+\subsection{Fair Exchange and Endorsements}
+Camenisch describes a version of (offline) e-cash where it is possible to
+generate lightweight endorsement for coins.  These endorsements are unlinkable from
+each other and from the coin.  An endorsement allows the implementation of fair exchange
+(where either both goods are exchanged and a payment is made or neither) without giving up
+anonymity.
 
-There is no exculpability game, since we do not have offline double spending detection.
+Taler trivially supports a similar concept of endorsements via the coin public key, deposit permissions and the
+refresh protocol.  The deposit permission (augmented with some additional data) can be viewed as an endorsement
+that enables fair exchange.  Unlinkability is guaranteed by the Refresh protocol.
 
 \section{Security Definitions}
 We say that an e-cash scheme satisfies anonymity if  ...