Discussion of income transperency hiccup

1 files changed, 58 insertions, 0 deletions

diff --git a/games/games.tex b/games/games.tex
index d479d6a..265cbf3 100644
--- a/games/games.tex
+++ b/games/games.tex
@@ -614,6 +614,64 @@ It follows that
  $P[{b \over w'} \ge (1-{1\over\kappa})] = 1/2 > {1\over\kappa}$.
 \end{proof}
 
+We observe that $t C' = c' T$ provides a delicate requirement for
+implementations:  An exchange might do the scalar multiplication by
+the basepoint $T = t G$ differently than the abritrary scalar
+multiplication $t C'$, in curve25519 say by clearing the low bits
+to multiply by the cofactor for $t G$ but not for $t C'$.  
+In this case, the customer could still reclaim the coin by running
+refreshes with each possible cofactor deviation.  
+
+As using the linking protocol risks anonmity, we do not implement it
+ourselves and permit taxability to rest on the threat of a customer
+implemneting it because a merchant asks them to use a wallet modified
+for tax evasion.  We feel this threat is more credible if said
+customer does not need to understand cofactors.
+
+in this vein, there are modifications of Taler in which the customer
+has no efficent algorithm to correct $t C' \neq c' T$:
+ 
+Our blinding operation is information theoretically secure of course,
+so withdrawn coins information theoretic, and hence post-quantum,
+anonymity, while refreshed coins clearly lack post-quantum anonymity.
+We lack post-quantum security for all our RSA and Ed25519 signature
+schemes too of course, but this only presents problems once quantum 
+computers actually exist. 
+
+We might worry that refreshed coins might deanonymize current users
+to an adversary who copies the databases of exchanges and merchants
+today and only develops quantum computers in the future.  
+How should we adapt Taler to defeat this adversary?  
+
+We could extend the coin signing key $C$ to be a pair $(C,P)$ in
+which $P$ is a public key for some post-quatum key exchange, but
+doing so requires that the post quantum key exchange provides the
+equivelent of $t C' = c' T$.  
+
+In Ring-LWE schemes for example,
+there is usualy a risk that the reconciliation part of the key
+exchange fails to compute the correct result.  These schemes
+make this risk low, but since the income adversary knowsn both
+sides private keys they can seemingly always construct transfer
+private keys that break income transperency.
+
+There is no such problem with supersingular isogenies Diffie-Hellman
+key exchange (SIDH) per se, but currently it remains about a hundred
+times slower than curve25519.  As the SIDH public keys must be check
+in refresh, this adds $\kappa$ expensive SIDH operations per refresh,
+which sounds unacceptable.
+
+As it turns out, there is a simple hash-based solutions that works
+because the coin holder is encrypting to themselves:  
+We extend the coin private key $c$ by a secret $m$ and extend the
+coin signing key $C$ to be a pair $(C,R)$ in which $R$ is the root
+of a Merkle tree whose $i$th leave is $H(m,i)$.
+In a refresh, the wallet first constructs the planchets from 
+$H(t C', H(m,i))$ and commits to the index $i$ along with with each
+transfer public key $T$, and later when revealing $t$ also reveals 
+$H(m,i)$ and the proof that it lives in the Merkle tree.  
+% Anything about fragility?
+
 
 \section{Standard Definitions}
 \begin{definition}[One-more forgery]