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

Structure and DRM comments. Christian will be amused.

Browse Source
This commit is contained in:
Jeffrey Burdges 2017-05-30 08:32:55 +02:00
parent a1c32c9554
commit 2177b81140
No known key found for this signature in database
GPG Key ID: ABAC7FD1CC100A74
1 changed files with 43 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
doc/paper/taler.tex
View File

@ -1277,8 +1277,8 @@ Let $C$ denote a coin controlled by users Alice and Bob.
Suppose Bob creates a fresh coin $C'$ from $C$ following the refresh protocol. Suppose Bob creates a fresh coin $C'$ from $C$ following the refresh protocol.
Assuming the exchange and Bob operated the refresh protocol correctly, Assuming the exchange and Bob operated the refresh protocol correctly,
and that the exchange continues to operate the linking protocol and that the exchange continues to operate the linking protocol
in \S\ref{subsec:linking} correctly, in \S\ref{subsec:linking} correctly, then
then Alice can gain control of $C'$ using the linking protocol. Alice can gain control of $C'$ using the linking protocol.
\end{theorem} \end{theorem}
\begin{proof} \begin{proof}
@ -1294,9 +1294,24 @@ for the residual value on $C'$ and runs the linking protocol to
determine if it was refreshed too. determine if it was refreshed too.
\end{proof} \end{proof}
As discussed in the next subsection, there are serious privacy risks
from coins obtained through the linking protocol, so we must not
implement the linking protocol in the wallet ourselves.
We assert that Taler is taxable on the grounds that any user who
modified their wallet to operate dishonestly could similarly modify
it to use the linking protocol to cheat other users.
Although this claims holds broadly, one could envision violating it
with advanced forms of Digital Restrictions Management (DRM) that
exploited trusted code execution. We discount this threat as being
similar to the withdrawal loophole, but we recommend that hardware
DRM be outlawed for posing a threat to the state's tax base, along
with more serious concerns.
\begin{corollary} \begin{corollary}
Abusing the refresh protocol to transfer ownership has an Assuming the user can operate their computer freely,
expected loss of $1 - \frac{1}{\kappa}$ of the transaction value. abusing the refresh protocol to transfer ownership has an
expected loss of $1 - \frac{1}{\kappa}$ of the transaction value.
\end{corollary} \end{corollary}
@ -1328,35 +1343,39 @@ $b m^d \mod n$ where $m$ is the FDH of the coin's public key
and $b$ is the blinding factor, while coin deposits transcripts and $b$ is the blinding factor, while coin deposits transcripts
consist of only $m^d \mod n$. consist of only $m^d \mod n$.
Of course, if the adversary can link coins then they can compute If the adversary can link coins then they can compute the blinding
the blinding factors as $b m^d / m^d \mod n$. Conversely, if the factors as $b m^d / m^d \mod n$. Conversely, if the adversary can
adversary can recognize blinding factors then they link coins after recognize blinding factors then they link coins after first computing
first computing $b_{i,j} = b_i m_i^d / m_j^d \mod n$ for all $i,j$. $b_{i,j} = b_i m_i^d / m_j^d \mod n$ for all $i,j$.
\end{proof} \end{proof}
We now know the following because Taler uses SHA512 adopted to be % As a corollary, Taler would have information theoretic privacy
a FDH to be the blinding factor. % if the blinding factors were truly random and
% refresh operations were disallowed.
We actually generate blinding factors using an FDH built by
running HMAC-SHA512 on a secret 256 bit seed and a count until
it outputs a number $b$ less than $n$ satisfying $\gcd(b,n) = 1$.
\begin{corollary} \begin{corollary}
Assuming no refresh operation, Assuming no refresh operation,
any adversary with an advantage for linking Taler coins gives any adversary with an advantage for linking Taler coins gives rise
rise to an adversary with an advantage for recognizing SHA512 output. to an adversary with an advantage for recognizing our SHA512 output.
\end{corollary} \end{corollary}
Importantly, we do not consider coins about which wallet learns Importantly, we do not consider coins about which wallet learns
through the linking protocol given in \S\ref{subsec:linking}. through the linking protocol given in \S\ref{subsec:linking}.
An honest participant never needs to run the linking protocol, An honest participant never needs to run the linking protocol,
so these coins should not appear, and we do not count them in so these coins should not appear, and we do not count them in
the adversary's advantage. If linked coins do appear, then the adversary's advantage. If linked coins do appear, then
they cannot be spent anonymously because the other user controlling they cannot be spent anonymously because the other user controlling
the coin can learn about any transactions involving these coins. the coin can learn about any transactions involving these coins.
Worse still, the exchange itself could issue tagged coins through Worse still, the exchange itself could issue tagged coins through
the linking protocol. As a result, we limit the refresh protocol to the linking protocol. As a result, we limit the refresh protocol to
a feature offered by the exchange, and test it from the auditor, but a feature offered by the exchange, and test it from the auditor, but
do not use it in any real Taler protocols and do not implement it in do not use it in any real Taler protocols and do not implement it in
the wallet. A user who modified their wallet to operate dishonestly the wallet. We observed in the previous subsection that merely
could similarly modify it to use the linking protocol to cheat the threat of the linking protocol suffices for taxability.
other users.
\smallskip \smallskip
@ -1369,10 +1388,10 @@ encrypted using the secret $t^{(i)} C_s$ where $C_s = c_s G$ of the
dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the
transfer key. transfer key.
% %
In Taler, we replaced this encryption-based scheme with the current KDF-based In Taler, we replaced this encryption-based scheme with the current
scheme, as the earlier scheme required slightly more storage space, an KDF-based scheme, as the earlier scheme required more storage space,
additional encryption primitive, and exposed more random number generator an additional encryption primitive, and exposed more random number
output from the wallet. generator output from the wallet.
\begin{proposition} \begin{proposition}
Assume the encryption used is semantically (IND-CPA) secure, Assume the encryption used is semantically (IND-CPA) secure,
@ -1381,7 +1400,7 @@ Assume also the independence of $c_s$, $t$, and the new coins' key
materials. materials.
Then any probabilistic polynomial time (PPT) adversary with an 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 our SHA512 output.
\end{proposition} \end{proposition}
% TODO: Is independence here too strong? % TODO: Is independence here too strong?
@ -1429,9 +1448,9 @@ $t$ also learns $k$.
We may now conclude that Taler remains unlinkable even with the We may now conclude that Taler remains unlinkable even with the
refresh protocol, assuming the security of elliptic curve Diffie-Hellman refresh protocol, assuming the security of elliptic curve Diffie-Hellman
key exchange on curve25519 and that SHA512 remains strong enough. key exchange on curve25519 and that our SHA512 HMAC construction remains
We have lost our clean assumption on merely the hardness of strong enough. We have lost our clean assumption on merely the hardness
recognizing SHA512 output, due to using the random oracle model, of recognizing our SHA512 output, due to using the random oracle model,
but recognizing has output remains the most realistic attack. but recognizing has output remains the most realistic attack.
We use an HMAC in our implementation to make this part more robust. We use an HMAC in our implementation to make this part more robust.