From 4680392d21494b47a7e0de8ce2c9853cf6f11f29 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Tue, 18 Sep 2018 11:11:53 +0200 Subject: format for 15 pages --- taler-fc19/paper.tex | 39 +++++++++++++++++++-------------------- 1 file changed, 19 insertions(+), 20 deletions(-) (limited to 'taler-fc19') diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex index baa7b14..3fae525 100644 --- a/taler-fc19/paper.tex +++ b/taler-fc19/paper.tex @@ -157,7 +157,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 +241,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 +258,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 +279,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 +298,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))$: -- cgit v1.2.3