From 468a373df46eea54d024ac4c1bd0bebf548e2d0c Mon Sep 17 00:00:00 2001
From: Jeffrey Burdges <burdges@gnunet.org>
Date: Tue, 16 May 2017 13:59:48 +0200
Subject: [PATCH 1/2] IND-CPA maybe?

---
 doc/paper/taler.tex | 40 +++++++++++++++++++++++++---------------
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index c32adc1b9..1a695e12e 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1285,7 +1285,7 @@ We thank people (anonymized).
 \newpage
 
 \bibliographystyle{alpha}
-\bibliography{taler,rfc}
+\bibliography{taler,rfc,ro}
 
 %\vfill
 %\begin{center}
@@ -1455,10 +1455,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.
@@ -1466,7 +1465,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}
@@ -1488,7 +1487,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}
 
@@ -1498,12 +1497,22 @@ 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.
 
 \begin{proposition}
-Assuming the encryption used is ??? secure, and that
- the independence of $c$, $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$, $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 model
@@ -1516,18 +1525,19 @@ 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.
 \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.

From cd382c1b13fb363dcd68ee61d2ada8f58687bde3 Mon Sep 17 00:00:00 2001
From: Jeffrey Burdges <burdges@gnunet.org>
Date: Tue, 16 May 2017 14:05:37 +0200
Subject: [PATCH 2/2] Slight cleanup after merge

---
 doc/paper/taler.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 607390e24..aaeb72b25 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,ro} % rfc
+\bibliography{taler,rfc,ro}
 
-\end{document} %TODO: What?!?
+%\end{document}
 
 %\vfill
 %\begin{center}