taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

IND-CPA maybe?

Browse Source
This commit is contained in:
Jeffrey Burdges 2017-05-16 13:59:48 +02:00
parent 49f590d8dc
commit 468a373df4
No known key found for this signature in database
GPG Key ID: ABAC7FD1CC100A74
1 changed files with 25 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/paper/taler.tex
View File

@ -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.