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

Improve proof, remove false generality

Browse Source
This commit is contained in:
Jeffrey Burdges 2017-05-22 15:16:29 +02:00
parent 6876e3178d
commit a838af7dda
No known key found for this signature in database
GPG Key ID: ABAC7FD1CC100A74
1 changed files with 35 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
doc/paper/taler.tex
View File

@ -1375,9 +1375,11 @@ additional encryption primitive, and exposed more random number generator
output from the wallet. output from the wallet.
\begin{proposition} \begin{proposition}
Assuming the encryption used is semantically (IND-CPA) secure, and Assume the encryption used is semantically (IND-CPA) secure,
the independence of $c_s$, $t$, and the new coins' key materials, given the security of a Diffie-Hellman key exchange over curve25519.
then any probabilistic polynomial time (PPT) adversary with an Assume also 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 advantage for linking Taler coins gives rise to an adversary with
an advantage for recognizing SHA512 output. an advantage for recognizing SHA512 output.
\end{proposition} \end{proposition}
@ -1388,48 +1390,48 @@ a dishonest customer who uses the linking protocol. We ignore this
because we exclude such coins from our privacy garentees and the because we exclude such coins from our privacy garentees and the
exchange can even invent coins whole cloth. exchange can even invent coins whole cloth.
We may now remove the encrpytion by appealing to the random oracle We shall now replace the encrpytion phase with a KDF as in our actual
model~\cite{BR-RandomOracles}. protocol, except we treat the KDF as a random oracle~\cite{BR-RandomOracles}.
%
\begin{lemma}%[\cite{??}] In fact, we expect doing so to increase practical security as in
Consider a protocol that commits to random data by encrypting it
using a secret derived from a Diffe-Hellman key exchange.
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: Too general probably?
% TODO: IND-CPA again?
Indeed, we expect doing so to increase practical security as in
\cite{Abdalla2000}, and adding the random oracle assumption need not \cite{Abdalla2000}, and adding the random oracle assumption need not
reduce security if it focuses more attention on the usage of hash reduce security if it focuses more attention on the usage of hash
functions throughout the protocol. functions throughout the protocol.
\begin{theorem}
In the random oracle model, any PPT adversary with an advantage
in linking Taler coins has an advantage in breaking elliptic curve
Diffie-Hellman key exchange on curve25519.
\end{theorem}
% TODO: IND-CPA again anywhere?
\begin{proof} \begin{proof}
We work with the usual instantiation of the random oracle model as We work with the usual instantiation of the random oracle model as
returning a random string and placing it into a database for future returning a random string and placing it into a database for future
queries. queries.
We take the random number generator that drives one random oracle $R$ We have a shared secret $k$ derived from an ECDH from which we derive
to be the random number generator used to produce the random data the encryption key used in the old protocol to encrypt the new coin's
that we encrypt in the old encryption based version of Taler. blinding factor and private key. We now choose to generate the new
Now our random oracle scheme with $R$ gives the same result as our coin's blinding factor and private key using a random oracle $R$
scheme that encrypts random data, so the encryption becomes keyed by $k$. We can do this because first the data is encrypted and
superfluous and may be omitted. second revealing the new coin's blinding factor or public or private
keys later reveals nothing about $k$, thanks to \cite[Theorem 4.1]{Rudich88}.
We require the security of the original encryption operation reduced After this modfication, our real KDF scheme with the KDF instantiated
to the security of the Diffe-Hellman key exchange, which remains a by the random oracle $R$ gives the same result as our scheme that
requirement of the derived protocol. encrypts data produced by $R$. We now observe the encryption has
becomes superfluous and may be omitted, as another party who learns
$t$ also learns $k$.
\end{proof} \end{proof}
We may now conclude that Taler remains unlinkable even with the refresh protocol. We may now conclude that Taler remains unlinkable even with the
refresh protocol, assuming the security of elliptic curve Diffie-Hellman
\begin{theorem} key exchange on curve25519 and that SHA512 remains strong enough.
In the random oracle model, any PPT adversary with an advantage We have lost our clean assumption on merely the hardness of
in linking Taler coins has an advantage in breaking elliptic curve recognizing SHA512 output, due to using the random oracle model,
Diffie-Hellman key exchange on Curve25519. but recognizing has output remains the most realistic attack.
\end{theorem} We use an HMAC in our implementation to make this part more robust.
We do not distinguish between information known by the exchange and We do not distinguish between information known by the exchange and
information known by the merchant in the above. As a result, this information known by the merchant in the above. As a result, this