Merge branch 'master' of ssh://taler.net/papers

1 files changed, 35 insertions, 31 deletions

diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex
index a94ec38..c76b15d 100644
--- a/taler-fc19/paper.tex
+++ b/taler-fc19/paper.tex
@@ -30,11 +30,12 @@
   backup or synchronized with other devices.  We argue from this position that

   a protocol for unlinkable change is necessary even in schemes that provide

   divisibility. As a na\"ive implementation of a change protocol opens up the

-  possibility of abuse for tax evasion, we define an income transparency

+  possibility of abuse for tax evasion, we define a new \emph{income transparency}

   security property.

 

   We furthermore show that an e-cash protocol that fulfills these properties

-  can be used to implement Camenisch-style fair exchange, tick payments, and

+  can be used to implement Camenisch-style fair exchange, tick payments,

+  and

   can be used to provide anonymous refunds.

 \keywords{E-cash  \and blind signature \and key exchange}

 \end{abstract}

@@ -157,7 +158,7 @@ or $\V{refreshed}$ lists nor in $\V{acceptedContracts}$.  We say that a coin is
 being $\V{overspent}$ if recording an operation in $\V{deposited}$ or

 $\V{refreshed}$ would cause the total spent value from both lists to exceed

 the value of the coin's denomination.

-

+%

 Note that the adversary does not have direct read or write access to these

 values; instead the adversary needs to use the oracles (defined in Section~\ref{sec:oracles}) to

 interact with the system.

@@ -241,11 +242,10 @@ of parties maintained by the challenger in the security games which we define la
     denomination requested in the corresponding $\algo{WithdrawRequest}$

     execution.  How exactly $\V{pkD}$ is restored depends on the particular instantiation.

 

-    The resulting coin

-    \[ \V{coin} = (\V{skCoin}, \V{pkCoin}, \V{pkD}, \V{coinCert}) \]

-    (consisting of secret key $\V{skCoin}$, public key

-    $\V{pkCoin}$, denomination public key $\V{pkD}$ and certificate $\V{coinCert}$ from the exchange) is stored

-    in the customers wallet $\V{wallet}[\V{pkCustomer}]$.

+    The resulting coin $\V{coin} := (\V{skCoin}, \V{pkCoin}, \V{pkD}, \V{coinCert})$,

+    consisting of secret key $\V{skCoin}$, public key

+    $\V{pkCoin}$, denomination public key $\V{pkD}$ and certificate $\V{coinCert}$ from the exchange,

+    is stored in the customers wallet $\V{wallet}[\V{pkCustomer}]$.

 

     Executing the $\algo{WithdrawPickup}$ protocol multiple times with the same

     customer and the same withdraw identifier does not result in any change of

@@ -259,20 +259,20 @@ of parties maintained by the challenger in the security games which we define la
     Algorithm to produce and sign a deposit permission \V{depositPermission}

     for a coin under a particular transaction identifier.  The fraction $0 < f \le 1$ determines the

     fraction of the coin's initial value that will be spent.

-

+%

     The contents of the deposit permission depend on the instantiation, but it

     must be possible to derive the public coin identifier $\V{pkCoin}$ from

     them.

 

   \item $\algo{Deposit}(\prt{E}(\V{sksE}, \V{pkMerchant}), \prt{M}(\V{skMerchant}, \V{pksE}, \V{depositPermission})) \mapsto \mathcal{T}_D$:

     Interactive protocol between the exchange and a merchant.

-

+%

     From the deposit permission we obtain the $\V{pkCoin}$ of the coin to be

     deposited.  If $\V{pkCoin}$ is being overspent, the protocol is aborted with

     an error message to the merchant.

-

+%

     On success, we add $\V{depositPermission}$ to $\V{deposited}[\V{pkCoin}]$.

-

+%

     Returns a protocol transcript $\mathcal{T}_D$ of all messages exchanged

     between the exchange and merchant.

 

@@ -280,18 +280,18 @@ of parties maintained by the challenger in the security games which we define la
       \rightarrow (\mathcal{T}_{RR}, \V{rid})$

     Interactive protocol between exchange and customer that initiates a refresh

     of $\V{coin}_0$.  Together with $\algo{RefreshPickup}$, it allows the

-    customer to convert $D(\V{pkD}_u)$ of the remaining value on coin \[

-      \V{coin}_0 = (\V{skCoin}_0, \V{pkCoin}_0, \V{pkD}_0, \V{coinCert}_0) \]

+    customer to convert $D(\V{pkD}_u)$ of the remaining value on coin

+    $\V{coin}_0 = (\V{skCoin}_0, \V{pkCoin}_0, \V{pkD}_0, \V{coinCert}_0)$

     into a new, unlinkable coin $\V{coin}_u$ of denomination $\V{pkD}_u$.

-

+%

     Multiple refreshes on the same coin are allowed, but each run subtracts the

     respective financial value of $\V{coin}_u$ from the remaining value of

     $\V{coin}_0$.

-

+%

     The customer only records the refresh operation identifier $\V{rid}$ in

     $\V{refreshIds}[\V{pkCustomer}]$, but does not yet obtain the new coin.  To

     obtain the new coin, \algo{RefreshPickup} must be used.

-

+%

     Returns the protocol transcript $\mathcal{T}_{RR}$ and a refresh identifier $\V{rid}$.

 

   \item $\algo{RefreshPickup}(\prt{E}(\V{sksE}, \V{pkCustomer}),

@@ -299,28 +299,28 @@ of parties maintained by the challenger in the security games which we define la
     Interactive protocol between exchange and customer to obtain the new coin

     for a refresh operation previously started with \algo{RefreshRequest},

     identified by the refresh identifier $\V{rid}$.

-

+%

     The first time \algo{RefreshPickup} is run for a particular refresh

     identifier, the exchange tries to record the refresh operation of value $D(\V{pkD}_u)$

     in $\V{refreshed}[\V{pkCoin}_0]$, with $\V{pkD}_u$ and $\V{pkCoin}_0$ taken

     from the corresponding $\algo{RefreshRequest}$ that resulted in $\V{rid}$.

     How exactly the exchange obtains $\V{pkD}_u$ and $\V{pkCoin}_0$ depends on

     the instantiation.

-

+%

     If $\V{pkCoin}_0$ is being overspent, the refresh operation is not recorded

     in $\V{refreshed}[\V{pkCoin}_0]$, the exchange sends the customer the

     protocol transcript of the previous deposits and refreshes and aborts the

     protocol.

-

+%

     If the customer \prt{C} plays honestly in \algo{RefreshRequest} and

     \V{RefreshPickup}, the unlinkable coin $\V{coin}_i$ they obtain as change

     will be stored in their wallet $\V{wallet}[\V{pkCustomer}]$.  If \prt{C} is

     caught playing dishonestly, the \algo{RefreshPickup} protocol aborts.

-

+%

     An honest customer must be able to repeat a \algo{RefreshPickup} with the

     same $\V{rid}$ multiple times and (re-)obtain the same coin, even if

     previous $\algo{RefreshPickup}$ executions were aborted.

-

+%

     Returns a protocol transcript $\mathcal{T}_{RP}$.

 

   \item $\algo{Link}(\prt{E}(\V{sksE}), \prt{C}(\V{skCustomer}, \V{pksE}, \V{coin}_0)) \rightarrow (\mathcal{T}, (\V{coin}_1, \dots, \V{coin}_n))$:

@@ -591,7 +591,7 @@ money or privacy.
   \setlength\itemsep{0em}

   \item $(\V{sksE}, \V{pksE}) \leftarrow \mathrm{ExchangeKeygen}(1^\lambda, 1^\kappa, M)$ 

   \item $\V{pkCustomer} \leftarrow {\cal A}^{\oraSet{NoShare}}(\V{pksE})$

-  \item Return $0$ if $\V{pkCustomer}$ is not an uncorrupted, registered user.

+  \item Return $0$ if $\V{pkCustomer}$ is a corrupted user.

   \item \label{game:conserv:run} Run $\algo{WithdrawPickup}$ for each withdraw identifier $\V{wid}$

     and $\algo{RefreshPickup}$ for each refresh identifier $\V{rid}$ that the user

     has recorded in $\V{withdrawIds}$ and $\V{refreshIds}$.  Run $\algo{Deposit}$

@@ -780,19 +780,23 @@ We require the following two security properties for $\textsc{BlindSign}$:
 \begin{itemize}

   \item \emph{blindness}: Let $M$ be the set of all possible messages and $\overline{M}$ be the

     set of all possible blinded messages. Then the distribution of

-    \[ \left\{ (m, \simga, \overline{m}, \overline{\simga}) \,\middle| 

-	   m\, \randsel M, 

-	   \overline{m} \leftarrow \algo{Blind}_{BS}(\mathcal{S}(\V{sk}), m),

-	   \overline{\simga} \leftarrow \algo{Sign}_{BS}(\V{sk}, \overline{m}),

+    \[ \left\{ (m, \sigma, \overline{m}, \overline{\sigma}) \,\middle|

+          \begin{array}{c}

+	   m\, \randsel M, \\

+	   \overline{m} \leftarrow \algo{Blind}_{BS}(\mathcal{S}(\V{sk}), m), \\

+	   \overline{\sigma} \leftarrow \algo{Sign}_{BS}(\V{sk}, \overline{m}), \\

 	   \sigma \leftarrow \algo{UnblindSig}_{BS}(r, m, \overline{\sigma})

+          \end{array}

 	   \right\} \]

     must be computationally

     indistinguishable from

-    \[ \left\{ (m, \simga, x, \simga_x) \,\middle|\, 

-	   m \randsel M, 

-	   \sigma \eftarrow \algo{UnblindSig}_{BS}(r, m, \algo{Sign}_{BS}(\V{sk}, \algo{Blind}_{BS}(\mathcal{S}(\V{sk}), m)) )

-	   x \randsel \overline{M},

+    \[ \left\{ (m, \sigma, x, \sigma_x) \,\middle|\,

+          \begin{array}{c}

+           m \randsel M,  \\

+	   \sigma \leftarrow \algo{UnblindSig}_{BS}(r, m, \algo{Sign}_{BS}(\V{sk}, \algo{Blind}_{BS}(\mathcal{S}(\V{sk}), m)) ) \\

+	   x \randsel \overline{M}, \\

 	   \sigma_x \leftarrow \algo{UnblindSig}_{BS}(r, x, \algo{Sign}_{BS}(\V{sk}, \algo{Blind}_{BS}(\mathcal{S}(\V{sk}), x)) )

+          \end{array}

 	   \right\}. \]

   \item \emph{unforgeability}:  An adversary that requests $k$ signatures with $\algo{Sign}_{BS}$

     is unable to produce $k+1$ valid signatures with non-negligible probability.