gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [taler-exchange] branch master updated: english, linking


From: gnunet
Subject: [GNUnet-SVN] [taler-exchange] branch master updated: english, linking
Date: Tue, 16 May 2017 13:34:17 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new 7b4b0f3  english, linking
7b4b0f3 is described below

commit 7b4b0f38ffd212587ac46ff035e1ac3573bd104a
Author: Christian Grothoff <address@hidden>
AuthorDate: Tue May 16 13:34:17 2017 +0200

    english, linking
---
 doc/paper/taler.tex | 32 ++++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index c32adc1..8b48ad8 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1492,29 +1492,35 @@ any PPT adversary with an advantage for linking Taler 
coins gives
 rise to an adversary with an advantage for recognizing SHA512 output.
 \end{corollary}
 
-There was an earlier encryption-based version of the Taler protocol
-in which refresh operated consisted of $\kappa$ normal coin withdrawals
-encrypted using the secret $t^{(i)} C$ where $C = c G$ is the coin being
-refreshed and $T^{(i)} = t^{(i)} G$ is the transfer key.
+We will now consider the impact of the refresh operation.  For the
+sake of the argument, we will first consider an earlier
+encryption-based version of the protocol in which refresh operated
+consisted of $\kappa$ normal coin withdrawals where the commitment
+consisted of the blinding factors and private keys of the fresh coins
+encrypted using the secret $t^{(i)} C_s$ where $C_s = c_s G$ of the
+dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the
+transfer key.\footnote{We abandoned that version as it required
+  slightly more storage space and the additional encryption
+  primitive.}
 
 \begin{proposition}
 Assuming the encryption used is ??? secure, and that
- the independence of $c$, $t$, and the new coins key materials, then
+ the independence of $c_s$, $t$, and the new coins' key materials, then
 any PPT adversary with an advantage for linking Taler coins gives
 rise to an adversary with an advantage for recognizing SHA512 output.
 \end{proposition}
 
 % TODO: Is independence here too strong?
 
-We may now remove the encrpytion by appealing to the random oracle model
-\cite{BR-RandomOracles}.
+We may now remove the encrpytion by appealing to the random oracle
+model~\cite{BR-RandomOracles}.
 
 \begin{lemma}[\cite{??}]
 Consider a protocol that commits to random data by encrypting it
 using a secret derived from a Diffe-Hellman key exchange.
 In the random oracle model, we may replace this encryption with
-a hash function derives the random data by applying hash functions
-to the same secret.
+a hash function which derives the random data by applying hash
+functions to the same secret.
 \end{lemma}
 
 \begin{proof}
@@ -1541,7 +1547,13 @@ Diffie-Hellman key exchange on Curve25519.
 We do not distinguish between information known by the exchange and
 information known by the merchant in the above.  As a result, this
 proves that out linking protocol \S\ref{subsec:linking} does not
-degrade privacy.
+degrade privacy.  We note that the exchange could lie in the linking
+protocol about the transfer public key to generate coins that it can
+link (at a financial loss to the exchange that it would have to square
+with its auditor).  However, in the normal course of payments the link
+protocol is never used.  Furthermore, if a customer needs to recover
+control over a coin using the linking protocol, they can use the
+refresh protocol on the result to again obtain an unlinkable coin.
 
 
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]