[GNUnet-SVN] [taler-exchange] 01/02: IND-CPA maybe?

[gnunet]

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

burdges pushed a commit to branch master
in repository exchange.

commit 468a373df46eea54d024ac4c1bd0bebf548e2d0c
Author: Jeffrey Burdges <address@hidden>
AuthorDate: Tue May 16 13:59:48 2017 +0200

    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 c32adc1..1a695e1 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.

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