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? --- 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