taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

minor edits to proofs

Browse Source
This commit is contained in:
Christian Grothoff 2017-05-16 15:50:42 +02:00
parent 09cd669283
commit 3bd606c8d8
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 23 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
doc/paper/taler.tex
View File

@ -1256,7 +1256,7 @@ advantage in solving the linking problem, when given the private
keys of the exchange. keys of the exchange.
In Taler, there are two forms of coin creation transcripts, In Taler, there are two forms of coin creation transcripts,
withdrawal and refresh. withdrawal and refresh.
\begin{lemma} \begin{lemma}
If there are no refresh operations, any adversary with an If there are no refresh operations, any adversary with an
@ -1288,7 +1288,7 @@ rise to an adversary with an advantage for recognizing SHA512 output.
\end{corollary} \end{corollary}
Importantly, we do not consider coins about which wallet learns Importantly, we do not consider coins about which wallet learns
through the linking protocol given in \S\ref{subsec:linking}. through the linking protocol given in \S\ref{subsec:linking}.
An honest participant never needs to run the linking protocol, An honest participant never needs to run the linking protocol,
so these coins should not appear, and we do not count them in so these coins should not appear, and we do not count them in
the adversary's advantage. If linked coins do appear, then the adversary's advantage. If linked coins do appear, then
@ -1304,7 +1304,7 @@ other users.
\smallskip \smallskip
We will now consider the impact of the refresh operation. We will now consider the impact of the refresh operation.
For the sake of the argument, we will first consider an earlier For the sake of the argument, we will first consider an earlier
encryption-based version of the protocol in which a refresh operated encryption-based version of the protocol in which a refresh operated
consisted of $\kappa$ normal coin withdrawals and the commitment consisted of $\kappa$ normal coin withdrawals and the commitment
@ -1343,7 +1343,7 @@ a hash function which derives the random data by applying hash
functions to the same secret. functions to the same secret.
\end{lemma} \end{lemma}
% TODO: Too general probably? % TODO: Too general probably?
% TODO: IND-CPA again? % TODO: IND-CPA again?
\begin{proof} \begin{proof}
We work with the usual instantiation of the random oracle model as We work with the usual instantiation of the random oracle model as
@ -1388,7 +1388,7 @@ obtains either a deposit-permission or a refresh-record, both of which
contain a signature made with the public key of coin to authorizing the contain a signature made with the public key of coin to authorizing the
respective operation. If the exchange has a set of refresh-records and respective operation. If the exchange has a set of refresh-records and
deposit-permissions whose total value exceed the value of the coin, the deposit-permissions whose total value exceed the value of the coin, the
exchange can show this set to prove that a coin was double-spend. exchange can show this set to prove that double-spending was attempted.
\end{proof} \end{proof}
\begin{corollary} \begin{corollary}
@ -1404,29 +1404,31 @@ when the merchant is faulty.
\end{lemma} \end{lemma}
\begin{proof} \begin{proof}
When the customer sends the deposit-permission for a coin When the customer sends the deposit-permission for a coin to a correct
to a correct merchant, the merchant will pass it on to the merchant, the merchant will pass it on to the exchange, and pass the
exchange, and pass the exchange's response, a deposit-confirmation, on exchange's response, a deposit-confirmation, on to the customer. If
to the customer. If a faulty merchant deposits the coin the customer does not receive a deposit-confirmation from the
but does not pass the deposit-confirmation to the customer, merchant, it will run the refresh protocol. If the faulty merchant
the customer will receive the deposit-confirmation as an error did deposit the coin, the customer will receive the
response from the refreshing protocol. Otherwise if the merchant deposit-confirmation as part of the double-spending proof from the
doesn't deposit the coin, the customer can get a new, unlinkable refreshing protocol. If the merchant did not deposit the coin, the
coin by running the refresh protocol. customer receives a new, unlinkable coin.
\end{proof} \end{proof}
\begin{corollary} \begin{corollary}
If a customer paid for a contract, they can prove it by showing If a customer paid for a contract signed by a merchant,
the deposit permissions for all coins. they can prove it by showing the deposit permissions for all coins.
\end{corollary} \end{corollary}
\begin{lemma} \begin{lemma}
The merchant can issue refunds, and only to the original customer. Only the merchant can issue refunds, and only to the original customer.
\end{lemma} \end{lemma}
\begin{proof} \begin{proof}
The refund protocol requires a signature matching the merchant's public
key, which had to be included in the original contract.
Since the refund only increases the balance of a coin that the original Since the refund only increases the balance of a coin that the original
customer owns, only the original customer can spend the refunded coin again. customer owns, only the original customer can use the increased balance.
\end{proof} \end{proof}
@ -1434,9 +1436,9 @@ customer owns, only the original customer can spend the refunded coin again.
The protocol prevents double-spending and provides exculpability. The protocol prevents double-spending and provides exculpability.
\end{theorem} \end{theorem}
\begin{proof} \begin{proof}
Follows from Lemma \ref{lemma:double-spending} and the assumption Follows from Lemma~\ref{lemma:double-spending} and the assumption
that the exchange can't forge signatures to obtain an incriminating that the exchange cannot forge signatures to obtain an fake
set of deposit-permissions and/or refresh-records. set of deposit-permissions or refresh-records.
\end{proof} \end{proof}