aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeffrey Burdges <burdges@gnunet.org>2017-05-16 13:59:48 +0200
committerJeffrey Burdges <burdges@gnunet.org>2017-05-16 13:59:48 +0200
commit468a373df46eea54d024ac4c1bd0bebf548e2d0c (patch)
treead534b0c807c529992ce20814b65d38af3632ac8
parent49f590d8dc88260741f035b7b1858e4e74d5ea45 (diff)
IND-CPA maybe?
-rw-r--r--doc/paper/taler.tex40
1 files 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.