From 2bc5b1e1df0286962548810dadb5848bd16fce39 Mon Sep 17 00:00:00 2001
From: Jeff Burdges
Date: Tue, 25 Sep 2018 10:22:30 0400
Subject: Fix commitment scheme
Is this correct? We encrypted somewhere once upon a time right?

talerfc19/paper.tex  34 +++++++++++
1 file changed, 11 insertions(+), 23 deletions()
diff git a/talerfc19/paper.tex b/talerfc19/paper.tex
index 8d48ead..602afc3 100644
 a/talerfc19/paper.tex
+++ b/talerfc19/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 SUFCMA.
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
bitstring.
+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 bitstring.
Let $\V{PRF}$ be a pseudorandom 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