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 (7ce6700 -> 88d6335)


From: gnunet
Subject: [GNUnet-SVN] [taler-exchange] branch master updated (7ce6700 -> 88d6335)
Date: Tue, 16 May 2017 14:04:13 +0200

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

burdges pushed a change to branch master
in repository exchange.

    from 7ce6700  use ACM sigconf format for 2017
     new 468a373  IND-CPA maybe?
     new 88d6335  Merge branch 'master' of ssh://taler.net/exchange

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 doc/paper/taler.tex | 42 ++++++++++++++++++++++++++----------------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 9cff69e..607390e 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1354,9 +1354,9 @@ We thank people (anonymized).
 \newpage
 
 \bibliographystyle{ACM-Reference-Format}
-\bibliography{taler} 
+\bibliography{taler,ro} % rfc
 
-\end{document}
+\end{document} %TODO: What?!?
 
 %\vfill
 %\begin{center}
@@ -1526,10 +1526,9 @@ if given coin creation transcripts and possibly fewer
 coin deposit transcripts for coins from the creation transcripts,
 then produce a corresponding creation and deposit transcript.
 
-We say a probabilistic polynomial time (PPT) adversary
-{\em links} coins if it has a non-negligible advantage in
-solving the linking problem, when given the private keys
-of the exchange.
+We say an adversary {\em links} coins if it has a non-negligible
+advantage in solving the linking problem, when given the private
+keys of the exchange.
 
 In Taler, there are two forms of coin creation transcripts,
 withdrawal and refresh.
@@ -1537,7 +1536,7 @@ withdrawal and refresh.
 \begin{lemma}
 If there are no refresh operations, any adversary with an
 advantage in linking coins is polynomially equivalent to an
-advantage with the same advantage in recognizing blinding factors.
+adversary with the same advantage in recognizing blinding factors.
 \end{lemma}
 
 \begin{proof}
@@ -1559,7 +1558,7 @@ We now know the following because Taler uses SHA512 
adopted to be
 
 \begin{corollary}
 Assuming no refresh operation,
-any PPT adversary with an advantage for linking Taler coins gives
+any adversary with an advantage for linking Taler coins gives
 rise to an adversary with an advantage for recognizing SHA512 output.
 \end{corollary}
 
@@ -1575,12 +1574,22 @@ transfer key.\footnote{We abandoned that version as it 
required
   primitive.}
 
 \begin{proposition}
-Assuming the encryption used is ??? secure, and that
- 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.
+Assuming the encryption used is semantically (IND-CPA) secure, and
+that the independence of $c_s$, $t$, and the new coins' key materials, 
+then any probabilistic polynomial time (PPT) adversary with an
+advantage for linking Taler coins gives rise to an adversary with
+ an advantage for recognizing SHA512 output.
 \end{proposition}
 
+In fact, the exchange can launch an chosen cphertext attack against
+the customer by providing different ciphertexts.  Yet, the resulting
+plaintext is implicitly authenticated becuase after decryption
+the customer unblinds and checks the signature by the denomination
+key.  
+
+If this check does not check out, then the wallet must abandon
+this coin and report the exchange's fraudulent activity.
+
 % TODO: Is independence here too strong?
 
 We may now remove the encrpytion by appealing to the random oracle
@@ -1593,18 +1602,19 @@ In the random oracle model, we may replace this 
encryption with
 a hash function which derives the random data by applying hash
 functions to the same secret.
 \end{lemma}
+% TODO: IND-CPA again?  Anything else?
 
 \begin{proof}
 We work with the usual instantiation of the random oracle model as
 returning a random string and placing it into a database for future
 queries.
 
-We take the random number generator that drives this random oracle
+We take the random number generator that drives one random oracle $R$
 to be the random number generator used to produce the random data
 that we encrypt in the old encryption based version of Taler.
-Now our random oracle scheme gives the same result as our scheme
-that encrypts random data, so the encryption becomes superfluous
-and may be omitted.
+Now our random oracle scheme with $R$ gives the same result as our
+scheme that encrypts random data, so the encryption becomes
+superfluous and may be omitted.
 \end{proof}
 
 We may now conclude that Taler remains unlinkable even with the refresh 
protocol.

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



reply via email to

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