From 2bc5b1e1df0286962548810dadb5848bd16fce39 Mon Sep 17 00:00:00 2001
From: Jeff Burdges <burdges@gnunet.org>
Date: Tue, 25 Sep 2018 10:22:30 -0400
Subject: Fix commitment scheme

Is this correct?  We encrypted somewhere once upon a time right?
---
 taler-fc19/paper.tex | 34 +++++++++++-----------------------
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex
index 8d48ead..602afc3 100644
--- a/taler-fc19/paper.tex
+++ b/taler-fc19/paper.tex
@@ -841,10 +841,10 @@ We require the following security properties to hold for $\textsc{CoinSignKx}$:
 Let $\textsc{Sign} = (\algo{KeyGen}_{S}, \algo{Sign}_{S}, \algo{Verify}_{S})$ be a signature
 scheme that satisfies SUF-CMA.
 
-Let $(\algo{Setup}_C, H_{pk})$ be a computationally hiding and binding
-commitment scheme, where $\algo{Setup}$ generates the public commitment key
-$pk$ and $H_{pk} : \{0,1\}^* \rightarrow \{0,1\}^\lambda$ deterministically commits to a
-bit-string.
+Let $(\algo{Setup}_C, H_{pk})$ be a computationally binding commitment
+scheme, where $\algo{Setup}$ generates the public commitment key $pk$
+and $H_{pk} : \{0,1\}^* \rightarrow \{0,1\}^\lambda$ deterministically
+commits to a bit-string.
 
 Let $\V{PRF}$ be a pseudo-random function family.
 
@@ -853,8 +853,9 @@ Using these primitive, we now instantiate the syntax:
 \begin{itemize}
   \item $\algo{ExchangeKeygen}(1^{\lambda}, 1^{\kappa}, \mathfrak{D})$:
 
-    Generate the exchange's signing key pair $\V{skESign} \leftarrow \algo{KeyGen}_{S}(1^\lambda)$ and public
-    commitment key $\V{CK} \leftarrow Setup_C(1^\lambda)$.
+    Generate the exchange's signing key pair
+	$\V{skESign} \leftarrow \algo{KeyGen}_{S}(1^\lambda)$ and
+	public commitment key $\V{CK} \leftarrow \algo{Setup}_C(1^\lambda)$.
     
     For each element in the sequence $\mathfrak{D} = d_1,\dots,d_n$, generate
     denomination key pair $(\V{skD}_i, \V{pkD}_i) \leftarrow \algo{KeyGen}_{BS}(1^\lambda)$.
@@ -1244,21 +1245,6 @@ Our instantiation satisfies {weak income transparency}.
 \end{theorem}
 
 \begin{proof}
-In our refresh operation, the commitment phase sends only the hash
-of blinded coins and transfer public keys to reduce bandwidth.  
-We therefore first convert our adversary into an adversary for a
-variant protocol in which these commitments contain the full values:  
-We rewind the adversary to try two distinct $\gamma \in 1,\dots,\kappa$ 
-during each refresh operation, so that we obtain all values.  
-We need  only try two choices because the adversary reveals all but
-one planchet in each run.  We now witness a hash collision if the
-transfer secret the adversary reveals does not yield the correct coins. 
-
-If Taler satisfies unforgeability then this variant protocol does so too,
-because an adversary against the protocol with commitment to full planchets
-can trivially be replaced by an adversary against the protocol with hash
-commitments.
-
   We consider the directed forest on coins induced by the refresh protocol.  
   It follows from unforgeability that any coin must originate from some
   customer's withdraw in this graph.
@@ -1290,8 +1276,10 @@ commitments.
   of $\textsc{CoinSignKx}$ applies to the coin public key.
   We assumed the $\gamma$-th transfer public key is honest too, so 
   our key exchange completeness assumption of $\textsc{CoinSignKx}$
-  yields $t C' \neq c' T$ where $T = t G$ is the transfer key,
-  so the customer obtains the correct transfer secret.
+  yields $t C' \neq c' T$ where $T = t G$ is the transfer key.
+  It follows our customer obtains the correct transfer secret and
+  derives the correct coins because our commitment scheme
+  $(\algo{Setup}_C, H_{pk})$ is computationally binding.
   We assumed the refresh concluded and all submissions besides the
   $\gamma$-th were honest, so the exchange correctly reveals the signed
   blinded coin.  We assumed the $\gamma$-th blinded coin is correct too,
-- 
cgit v1.2.3