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

de-HTMLize protocol description

Browse Source
This commit is contained in:
Christian Grothoff 2016-11-09 16:17:54 +01:00
parent 9a8d3c06bb
commit d3db993d3a
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 34 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
doc/paper/taler.tex
View File

@ -716,25 +716,24 @@ Now the customer carries out the following interaction with the exchange:
% It does create some confusion, like is a reserve key semi-ephemeral % It does create some confusion, like is a reserve key semi-ephemeral
% like a linking key? % like a linking key?
\begin{description} \begin{enumerate}
\item[Setup] The customer randomly generates: \item The customer randomly generates:
\begin{itemize} \begin{itemize}
\item reserve key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$, \item reserve key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$,
\item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$, \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$,
\item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk. \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk.
\end{itemize} \end{itemize}
\item[Wire transfer send] The customer then transfers an amount of money corresponding to
The customer transfers an amount of money corresponding to
at least $K_v$ to the exchange, with $W_p$ in the subject line at least $K_v$ to the exchange, with $W_p$ in the subject line
of the transaction. of the transaction.
\item[Wire transfer recieve] \item
The exchange receives the transaction and credits the reserve $W_p$ The exchange receives the transaction and credits the reserve $W_p$
with the respective amount in its database. with the respective amount in its database.
\item[POST {\tt /withdraw/sign}] \item
The customer computes $B := B_b(\FDH_K(C_p))$ and sends $S_W(B)$ to The customer computes $B := B_b(\FDH_K(C_p))$ and sends $S_W(B)$ to
the exchange to request withdrawal of $C$; here, $B_b$ denotes the exchange to request withdrawal of $C$; here, $B_b$ denotes
Chaum-style blinding with blinding factor $b$. Chaum-style blinding with blinding factor $b$.
\item[200 OK / 403 FORBIDDEN] \item
The exchange checks if the same withdrawal request was issued before; The exchange checks if the same withdrawal request was issued before;
in this case, it sends a Chaum-style blind signature $S_K(B)$ with in this case, it sends a Chaum-style blind signature $S_K(B)$ with
private key $K_s$ to the customer. \\ private key $K_s$ to the customer. \\
@ -752,11 +751,11 @@ Now the customer carries out the following interaction with the exchange:
error back to the customer, with proof that it operated correctly. error back to the customer, with proof that it operated correctly.
Assuming the signature was valid, this would involve showing the transaction Assuming the signature was valid, this would involve showing the transaction
history for the reserve. history for the reserve.
\item[Done] The customer computes the unblinded signature $U_b(S_K(B))$ and \item The customer computes the unblinded signature $U_b(S_K(B))$ and
verifies that $S_K(\FDH_K(C_p)) = U_b(S_K(B))$. verifies that $S_K(\FDH_K(C_p)) = U_b(S_K(B))$.
Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$ Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$
to their local wallet on disk. to their local wallet on disk.
\end{description} \end{enumerate}
\subsection{Exact and partial spending} \subsection{Exact and partial spending}
@ -777,53 +776,53 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
% FIXME: Again, these steps occur at different points in time, maybe % FIXME: Again, these steps occur at different points in time, maybe
% that's okay, but refresh is slightly different. % that's okay, but refresh is slightly different.
\begin{description} \begin{enumerate}
\item[Merchant Setup] % \label{contract} \item \label{contract}
Let $\vec{X} := \langle X_1, \ldots, X_n \rangle$ denote the list of Let $\vec{X} := \langle X_1, \ldots, X_n \rangle$ denote the list of
exchanges accepted by the merchant where each $X_j$ is a exchange's exchanges accepted by the merchant where each $X_j$ is a exchange's
public key. public key.
\item[Proposal] \item
The merchant creates a signed contract The merchant creates a signed contract
$\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})$ $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})$
where $m$ is an identifier for this transaction, $f$ is the price of the offer, where $m$ is an identifier for this transaction, $f$ is the price of the offer,
and $a$ is data relevant and $a$ is data relevant
to the contract indicating which services or goods the merchant will to the contract indicating which services or goods the merchant will
deliver to the customer, including the {\tt /merchant-specific} URI for the payment. deliver to the customer, including the merchant specific URI for the payment.
$p$ is the merchant's payment information (e.g. his IBAN number), and $p$ is the merchant's payment information (e.g. his IBAN number), and
$r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$ $r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$
to disk and sends $\mathcal{A}$ to the customer. to disk and sends $\mathcal{A}$ to the customer.
\item[Customer Setup] \item
The customer should already possess a coin $\widetilde{C}$ issued by a exchange that is The customer should already possess a coin $\widetilde{C}$ issued by a exchange that is
accepted by the merchant, meaning $K$ of $\widetilde{C}$ should be publicly signed by accepted by the merchant, meaning $K$ of $\widetilde{C}$ should be publicly signed by
some $X_j$ from $\vec{X}$, and has a value $\geq f$. some $X_j$ from $\vec{X}$, and has a value $\geq f$.
\item[POST {\tt /merchant-specific}] % \item
Let $X_j$ be the exchange which signed $\widetilde{C}$ with $K$. Let $X_j$ be the exchange which signed $\widetilde{C}$ with $K$.
The customer generates a \emph{deposit-permission} The customer generates a \emph{deposit-permission}
$\mathcal{D} := S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$ $$\mathcal{D} := S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$$
and sends $\langle \mathcal{D}, X_j\rangle$ to the merchant. and sends $\langle \mathcal{D}, X_j\rangle$ to the merchant. \label{step:first-post}
\item[POST {\tt/deposit}] \item
The merchant gives $(\mathcal{D}, p, r)$ to the exchange, thereby The merchant gives $(\mathcal{D}, p, r)$ to the exchange, thereby
revealing $p$ only to the exchange. revealing $p$ only to the exchange.
\item[200 OK / 403 FORBIDDEN] \item
The exchange validates $\mathcal{D}$ and checks for double spending. The exchange validates $\mathcal{D}$ and checks for double spending.
If the coin has been involved in previous transactions and the new If the coin has been involved in previous transactions and the new
one would exceed its remaining value, it sends a ``403 FORBIDDEN'' error one would exceed its remaining value, it sends an error
with the records from the previous transactions back to the merchant. \\ with the records from the previous transactions back to the merchant. \\
% %
If double spending is not found, the exchange commits $\langle \mathcal{D} \rangle$ to disk If double spending is not found, the exchange commits $\langle \mathcal{D} \rangle$ to disk
and signs a ``200 OK'' message affirming the deposit operation was successful. and signs a message affirming the deposit operation was successful.
\item[200 OK / 424 FAILED DEPENDENCY] \item
The merchant commits and forwards the notification from the exchange to the The merchant commits and forwards the notification from the exchange to the
customer, confirming the success (``200 OK'') or failure (``424 FAILED DEPENDENCY'') customer, confirming the success or failure
of the operation. of the operation.
\end{description} \end{enumerate}
We have simplified the exposition by assuming that one coin suffices, We have simplified the exposition by assuming that one coin suffices,
but in practice a customer can use multiple coins from the same but in practice a customer can use multiple coins from the same
exchange where the total value adds up to $f$ by running the above exchange where the total value adds up to $f$ by running the above
steps for each of the coins. steps for each of the coins.
If a transaction is aborted after the first POST, subsequent If a transaction is aborted after step~\ref{step:first-post}, subsequent
transactions with the same coin could be linked to this operation. transactions with the same coin could be linked to this operation.
The same applies to partially spent coins where $f$ is smaller than The same applies to partially spent coins where $f$ is smaller than
the actual value of the coin. To unlink subsequent transactions from the actual value of the coin. To unlink subsequent transactions from
@ -884,23 +883,23 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
% FIXME: I'm explicit about the rounds in postquantum.tex % FIXME: I'm explicit about the rounds in postquantum.tex
\begin{description} \begin{enumerate}
\item[POST {\tt /refresh/melt}] \item %[POST {\tt /refresh/melt}]
For each $i = 1,\ldots,\kappa$, the customer randomly generates For each $i = 1,\ldots,\kappa$, the customer randomly generates
a transfer private key $t^{(i)}_s$ and computes a transfer private key $t^{(i)}_s$ and computes
\begin{itemize} \begin{enumerate}
\item the transfer public key $T^{(i)}_p := t^{(i)}_s G$ and \item the transfer public key $T^{(i)}_p := t^{(i)}_s G$ and
\item the new coin secret seed $L^{(i)} := H(c'_s T_p^{(i)})$. \item the new coin secret seed $L^{(i)} := H(c'_s T_p^{(i)})$.
\end{itemize} \end{enumerate}
We have computed $L_i$ as a Diffie-Hellman shared secret between We have computed $L_i$ as a Diffie-Hellman shared secret between
the transfer key pair $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ the transfer key pair $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$
and old coin key pair $C' := \left(c_s', C_p'\right)$; and old coin key pair $C' := \left(c_s', C_p'\right)$;
as a result, $L^{(i)} = H(t^{(i)}_s C'_p)$ also holds. as a result, $L^{(i)} = H(t^{(i)}_s C'_p)$ also holds.
Now the customer applies key derivation functions $\KDF_{\textrm{blinding}}$ and $\KDF_{\textrm{Ed25519}}$ to $L^{(i)}$ to generate Now the customer applies key derivation functions $\KDF_{\textrm{blinding}}$ and $\KDF_{\textrm{Ed25519}}$ to $L^{(i)}$ to generate
\begin{itemize} \begin{enumerate}
\item a blinding factor $b^{(i)} = \FDH_K(\KDF_{\textrm{blinding}}(L^{(i)}))$. \item a blinding factor $b^{(i)} = \FDH_K(\KDF_{\textrm{blinding}}(L^{(i)}))$.
\item $c_s^{(i)} = \KDF_{\textrm{Ed25519}}(L^{(i)})$ \item $c_s^{(i)} = \KDF_{\textrm{Ed25519}}(L^{(i)})$
\end{itemize} \end{enumerate}
Now the customer can compute her new coin key pair Now the customer can compute her new coin key pair
$C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$ $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
where $C^{(i)}_p := c^{(i)}_s G$. where $C^{(i)}_p := c^{(i)}_s G$.
@ -914,7 +913,7 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$ The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$
for $i \in \{1,\ldots,\kappa\}$ and sends a commitment for $i \in \{1,\ldots,\kappa\}$ and sends a commitment
$S_{C'}(\vec{B}, \vec{T_p})$ to the exchange. $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
\item[200 OK / 409 CONFLICT] \item % [200 OK / 409 CONFLICT]
The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
marks $C'_p$ as spent by committing marks $C'_p$ as spent by committing
$\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk. $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk.
@ -923,12 +922,12 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
% %
The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where
$K'$ is the exchange's message signing key, thereby commmitting the exchange to $\gamma$. $K'$ is the exchange's message signing key, thereby commmitting the exchange to $\gamma$.
\item[POST {\tt /refresh/reveal}] \item % [POST {\tt /refresh/reveal}]
The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk.
Also, the customer assembles Also, the customer assembles
$\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$ $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
and sends $S_{C'}(\mathfrak{R})$ to the exchange. and sends $S_{C'}(\mathfrak{R})$ to the exchange.
\item[200 OK / 400 BAD REQUEST] % \label{step:refresh-ccheck} \item %[200 OK / 400 BAD REQUEST] % \label{step:refresh-ccheck}
The exchange checks whether $\mathfrak{R}$ is consistent with The exchange checks whether $\mathfrak{R}$ is consistent with
the commitments; specifically, it computes for $i \not= \gamma$: the commitments; specifically, it computes for $i \not= \gamma$:
@ -956,7 +955,7 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
blind signature $\widetilde{C} := S_{K}(B^{(\gamma)})$ to the customer. blind signature $\widetilde{C} := S_{K}(B^{(\gamma)})$ to the customer.
Otherwise, the exchange responds with an error indicating Otherwise, the exchange responds with an error indicating
the location of the failure. the location of the failure.
\end{description} \end{enumerate}
% FIXME: Maybe explain why we don't need n-m refreshing? % FIXME: Maybe explain why we don't need n-m refreshing?
% FIXME: What are the privacy implication of not having n-m refresh? % FIXME: What are the privacy implication of not having n-m refresh?