[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-exchange] branch master updated: implement feedback in cs thesis
|
From: |
gnunet |
|
Subject: |
[taler-exchange] branch master updated: implement feedback in cs thesis |
|
Date: |
Wed, 16 Feb 2022 21:59:50 +0100 |
This is an automated email from the git hooks/post-receive script.
lucien-heuzeveldt pushed a commit to branch master
in repository exchange.
The following commit(s) were added to refs/heads/master by this push:
new b73be40c implement feedback in cs thesis
b73be40c is described below
commit b73be40ccd9ad0ef4a985f252099c867f698896d
Author: Lucien Heuzeveldt <lucienclaude.heuzeveldt@students.bfh.ch>
AuthorDate: Wed Feb 16 21:59:41 2022 +0100
implement feedback in cs thesis
---
doc/cs/content/4_1_design.tex | 12 +-
doc/cs/content/5_discussion.tex | 12 +-
doc/cs/content/appendix/rsa-redesign.tex | 2 +-
doc/cs/content/chapter_01.tex | 35 -----
doc/cs/content/withdraw_loophole_remediation.tex | 160 -----------------------
doc/cs/thesis.tex | 2 +-
6 files changed, 14 insertions(+), 209 deletions(-)
diff --git a/doc/cs/content/4_1_design.tex b/doc/cs/content/4_1_design.tex
index 272f8da7..1d22b151 100644
--- a/doc/cs/content/4_1_design.tex
+++ b/doc/cs/content/4_1_design.tex
@@ -48,8 +48,8 @@ The following protocols currently use \gls{RSABS}:
\item Customer
\item Exchange
\end{itemize}
- \item \textbf{Payback Protocol:}
- The payback protocol distinguishes three different cases, which
either use the refresh protocol or disclose either the withdraw transcript or
refresh protocol transcript to the exchange.
+ \item \textbf{Recoup Protocol:}
+ The recoup protocol distinguishes three different cases, which
either use the refresh protocol or disclose either the withdraw transcript or
refresh protocol transcript to the exchange.
\\ Components:
\begin{itemize}
\item Customer
@@ -96,7 +96,7 @@ The coin and denomination private keys can be used as
long-term secrets due to t
Another question evolved around which key to use for the derivation of $ r_0,
r_1 $.
Obvious options are the denomination key or the exchange's online signing key.
-The denomination key was chosen because it has the payback protocol in place
that would handle coin recovery in case of a key compromise and subsequent
revocation.
+The denomination key was chosen because it has the recopu protocol in place
that would handle coin recovery in case of a key compromise and subsequent
revocation.
\begin{figure}[htp]
\begin{equation*}
@@ -376,7 +376,7 @@ In the reveal phase, the RSA signing and unblinding is
exchanged with Schnorr's
\\ & & \textbf{check } h_C = h_C'
\\ & & r_b := \text{HKDF}(256,n_r || d_s, \text{"r}b\text{"})
\\ & & \overline{s}_{C_p}^{(\gamma)} = r_b + \overline{c_{b_\gamma}} d_s
\mod p
- \\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
+ \\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{b, \overline{s}_C^{(\gamma)}} &
% Check coin signature and persist coin
% unblind signature
@@ -444,8 +444,8 @@ To re-obtain the derived coin, the same calculations as in
\ref{fig:refresh-deri
\subsection{Tipping}
Tipping remains unchanged, except for the content of the message $ \rho_W =
D_p, c_0, c_1 $ signed by the merchant using its reserve private key.
-\subsection{Payback Protocol}
-The payback protocol distinguishes three different cases, which all depend on
the state of a coin whose denomination key has been revoked.
+\subsection{Recoup Protocol}
+The recoup protocol distinguishes three different cases, which all depend on
the state of a coin whose denomination key has been revoked.
The following listing outlines the necessary changes on the protocol, please
refer to Dold's documentation section 2.2.1 \cite{dold:the-gnu-taler-system}
for details regarding the different cases.
\begin{itemize}
\item \textbf{The revoked coin has never been seen by the exchange}:
diff --git a/doc/cs/content/5_discussion.tex b/doc/cs/content/5_discussion.tex
index 1e1bcd5d..c68b4a79 100644
--- a/doc/cs/content/5_discussion.tex
+++ b/doc/cs/content/5_discussion.tex
@@ -192,9 +192,9 @@ The disk space comparison for a wallet can be found in
\ref{tab:comp-wallet-spac
\textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} &
\textbf{Disk Space 1M coins}\\\hline
CS 256 bits & 150 bytes & 1x & 150 MB\\\hline
RSA 1024 bit & 416 bytes & 2.7x & 416 MB \\\hline
- RSA 2048 bit & 800 bits & 5.3x & 800 MB\\\hline
- RSA 3072 bit & 1184 bits & 7.9x & 1184 MB\\\hline
- RSA 4096 bit & 1568 bits & 10.4x & 1568 MB\\\hline
+ RSA 2048 bit & 800 bytes & 5.3x & 800 MB\\\hline
+ RSA 3072 bit & 1184 bytes & 7.9x & 1184 MB\\\hline
+ RSA 4096 bit & 1568 bytes & 10.4x & 1568 MB\\\hline
\end{tabular}
\caption{Comparison disk space wallet}
\label{tab:comp-wallet-space}
@@ -225,9 +225,9 @@ Depending on the hash size another 32 byte (or 64 byte)
value is transmitted.
\textbf{Signature Scheme} & \textbf{Bandwith used} & \textbf{Factor} &
\textbf{1M coins}\\\hline
CS 256 bits & 356 bytes & 1x & 324 MB\\\hline
RSA 1024 bit & 448 bytes & 1.3x & 448 MB \\\hline
- RSA 2048 bit & 832 bits & 2.5x & 832 MB\\\hline
- RSA 3072 bit & 1216 bits & 3.75x & 1216 MB\\\hline
- RSA 4096 bit & 1600 bits & 4.9x & 1600 MB\\\hline
+ RSA 2048 bit & 832 bytes & 2.5x & 832 MB\\\hline
+ RSA 3072 bit & 1216 bytes & 3.75x & 1216 MB\\\hline
+ RSA 4096 bit & 1600 bytes & 4.9x & 1600 MB\\\hline
\end{tabular}
\caption{Bandwith comparison withdrawal}
\label{tab:comp-band-withd}
diff --git a/doc/cs/content/appendix/rsa-redesign.tex
b/doc/cs/content/appendix/rsa-redesign.tex
index 463b9735..4f66d907 100644
--- a/doc/cs/content/appendix/rsa-redesign.tex
+++ b/doc/cs/content/appendix/rsa-redesign.tex
@@ -159,7 +159,7 @@ The changes to the refresh protocol are related to the
derivation of transfer se
\\ & & h_C' = H(h_T', h_{\overline{m}}')
\\ & & \textbf{check } h_C = h_C'
\\ & & \overline{\sigma}_C^{(\gamma)} :=
\overline{m}^{d_{s(t)}}
- \\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
+ \\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
\\ &
\xleftarrow[\rule{2.5cm}{0pt}]{\overline{\sigma}_C^{(\gamma)}} &
% Check coin signature and persist coin
\\ \sigma_C^{(\gamma)} :=
r^{-1}\overline{\sigma}_C^{(\gamma)}
diff --git a/doc/cs/content/chapter_01.tex b/doc/cs/content/chapter_01.tex
deleted file mode 100644
index 5bb35445..00000000
--- a/doc/cs/content/chapter_01.tex
+++ /dev/null
@@ -1,35 +0,0 @@
-%!TEX root = ../dokumentation.tex
-
-\chapter{Das erste Kapitel}
-\section{Hello}
-Erste Erwähnung eines Akronyms wird als Fußnote angezeigt. Jede weitere wird
-nur verlinkt: \ac{AGPL}. Zweite Erwähnung \ac{AGPL}
-
-Verweise auf das Glossar: \gls{Glossareintrag}, \glspl{Glossareintrag}
-
-Nur erwähnte Literaturverweise werden auch im Literaturverzeichnis gedruckt:
-\cite{baumgartner:2002}, \cite{dreyfus:1980}
-\Gls{Glossareintrag}
-Meine erste Fußnote\footnote{Ich bin eine Fußnote}
-
-\begin{wrapfigure}{r}{.4\textwidth}
-\includegraphics[height=.4\textwidth]{taler.png}
-\vspace{-15pt}
-\caption{Das Logo der Musterfirma\footnotemark}
-\end{wrapfigure}
-%Quelle muss in Fußnote stehen (da sonst aufgrund eines Fehlers nicht
kompiliert
-% wird)
-\footnotetext{aus \cite{mustermann:2012}}
-Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text,
der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
-Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
-ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text,
der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz
langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text,
der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
-Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
-ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text,
der
-das Bild umfließt.
diff --git a/doc/cs/content/withdraw_loophole_remediation.tex
b/doc/cs/content/withdraw_loophole_remediation.tex
deleted file mode 100644
index 9e466aa7..00000000
--- a/doc/cs/content/withdraw_loophole_remediation.tex
+++ /dev/null
@@ -1,160 +0,0 @@
-\section{Remediation of the Withdraw Loophole}
-The withdraw loophole allows untaxed and untraceable payments by "misusing"
the withdraw protocol.
-It allows withdraw operations where owner of the resulting coins isn't the
owner of the reserve that the coins where withdrawn from.
-It is used for tipping and can therefore be seen as a feature.
-
-Using the withdraw loophole for payments is illustrated in figure
\ref{fig:withdraw-loophole-exploit}.
-Note that we omitted the parts leading up to the coin creation (contract,
agreement of price, number of coins and their denominations).
-This is how it works on a high level:
-\begin{enumerate}
- \item The malicous merchant generates and blinds coins, which are then
transmitted to the customer
- \item The customer authorizes the withdraw from his reserve by signing the
blinded coins with the private key of his reserve, thus generating withdraw
confirmations.
- \item The withdraw confirmations are transmitted to the exchange, which
generates the signatures and returns them to the malicous merchant.
- \item The malicous merchant unblinds the signatures.
- He is now in possession of the coin, thus the payment is completed.
-\end{enumerate}
-
-\begin{figure}[h]
- \begin{equation*}
- \begin{array}{ l c l}
- % preliminaries
- \text{Customer} & & \text{malicous Merchant}
- \\ \text{knows:} & & \text{knows:}
- \\ \text{reserve keys } w_s, W_p
- \\ \text{denomination public key } D_p = \langle e, N \rangle & &
\text{denomination public key } D_p = \langle e, N \rangle
- \\
- % generate coin
- \\ & & \text{generate coin key pair:}
- \\ & & c_s, C_p \leftarrow \text{Ed25519.KeyGen}()
- % blind
- \\ & & \text{blind:}
- \\ & & r \leftarrow random \in \mathbb{Z}_N^*
- \\ & & m' := \text{FDH}(N, C_p)*r^{e} \mod N
- % sing with reserve sk
- \\ & \xleftarrow[\rule{2cm}{0pt}]{m'}
- \\ \text{sign with reserve private key:}
- \\ \rho_W := \langle D_p, m' \rangle
- \\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W)
- \\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W
\rangle }
- \\
- % TODO add some kind of separator
- \hline
- \\
- \text{malicous Merchant} & & \text{Exchange}
- \\\text{knows:} & & \text{knows:}
- \\& & \text{reserve public key } W_p
- \\ \text{denomination public key } D_p = \langle e, N \rangle & &
\text{denomination keys } d_s, D_p
- \\
- \\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W
\rangle }
- \\ & & \langle D_p, m' \rangle := \rho_W
- \\ & & \text{verify if } D_p \text{ is valid}
- \\ & & \textbf{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
- \\ & & \text{decrease balance if sufficient}
- \\ & & \text{sign:}
- \\ & & \sigma'_c := (m')^{d_s} \mod N
- \\ & \xleftarrow[\rule{2cm}{0pt}]{\sigma'_c}
- \\ \text{unblind:}
- \\ \sigma_c := \sigma'_c*r^{-1}
- \\ \text{verify signature:}
- \\ \textbf{check if } \sigma_c = \text{FDH}(N, C_p)
- \\
- \\ \text{resulting coin: } \langle c_s, C_p, \sigma_c, D_p \rangle
- \end{array}
- \end{equation*}
- \caption{untaxed payment using withdraw loophole}
- \label{fig:withdraw-loophole-exploit}
-\end{figure}
-
-\subsection{Requirements For A Possible Solution}
-A viable solution has to fix the withdraw loophole, while still providing a
solution for tipping. In addition, Taler's security properties must not be
weakened.
-
-The underlying problem that has to be solved is to check that the person
withdrawing a coin is also the owner of the reserve used in the withdraw.
-This has to be solved in a way that prevents the customer and malicious
merchant to work together.
-
-% Requirements For A Perfect Solution}
-% minimal adjustments to Taler
-% Commitment to sk of Reserve -> constructed by customer (key owner)
-% commitment to sk of coin
-% how do we ensure that the customer is key owner? -> combine with reserve sk
-% how do we verify? problems with blinding
-% how do we ensure that the coin in the commitment is the coin that is
signed?
-% exchange must not learn anything about coin to prevent linking of withdraw
and transaction
-
-\subsection{Discussed Solution}
-For our proposed solution, a few adjustments to Taler have to be made:
-\begin{itemize}
- \item The withdraw confirmation must include a commitment to the public
key.
- This commitment must be constructed in a way that requires the customer to
know the public key.
- The exception to this are special tipping reserves (to preserve the
tipping feature).
- \item Cut-and-choose is added to the withdraw protocol.
- This means that the customer has to generate the coin and withdraw
confirmation $ k $ times.
- The exchange will then choose one of the $ k $ sessions.
- The customer has to reveal the coin public key, blinding secret and
commitment for all sessions except the chosen one.
- If the customer isn't able to deliver, the reserve is locked for future
withdraws until the other sessions are delivered.
- Cut-and-choose is introduced to verify whether the customer honestly
created the commitment and used the same coin public key for the signature
creation and the commitment.
- If the reserve is a special tip reserve (which has to be registered), this
check is omitted.
- \item An additional protocol is created that transfers the remaining value
of a coin back to the reserve if anyone is able to reveal the commitment from
the withdrawal.
- The adjustments described up to this point lead to the customer knowing
all the necessary values for using this protocol.
- Besides the customer, no one must be able to reproduce the commitment,
except in case of a reserve key compromise.
- \item Reserves are limited (usually only one, unless justified) and bound
to a customer (KYC).
- % this goes further than fixing the loophole. It prevents people from
creating new reserves that are then to be transfered
- % TODO check if there are disadvantages to this, especially regarding
privacy
- \item For a coin to be refreshable, it must have been seen by the exchange
before, meaning that it had to be used for a payment.
- The purpose of this is to prevent a malicious merchant to simply refresh a
coin after withdraw to prevent the customer from reverting the withdraw.
- \item For any coin used in a payment, the subtracted value must be higher
that a certain threshold (set globally or per denomination).
- For example, if the threshold is $ 10\% $, at least CHF 10 of a 100 CHF
coin must be used for a payment.
- The goal of this change is to prevent a malicious merchant from buying a
very cheap article to be able to refresh the coin.
-\end{itemize}
-
-The commitment has to fulfill the following properties:
-\begin{enumerate}
- \item It has to be constructed using the reserve private key and must be
verifiable using the corresponding public key.
- \item It has to include the coin public key.
- \item It has to be constructed in a way that ensures that the customer has
knowledge of the coin public key.
- \item Everyone with knowledge of the two keys must be able to recreate it.
-\end{enumerate}
-
-A possible commitment that partially satisfies the properties can be
constructed by hashing a signature of the coin's public key:
-\begin{equation*}
- H( \text{Ed25519.Sign} (w_w, C_p) )
-\end{equation*}
-Note that the PureEdDSA variant of Ed25519 has to be used for this.
-This variant doesn't hash the message before signing (see \cite{rfc8032} for
further details).\\
-It is still possible for a customer and a malicious merchant to construct the
commitment without the customer gaining knowledge of the coin public key.
-However, the customer has to share one half of the hash of the reserve private
key (which is practically one half of the private key, refer to section
\ref{sec:eddsa-signature-creation} for details about EdDSA signature creation).
-
-% was passiert wenn im Verhör und gezwungen wird, Keys herauszurücken?
-
-There is one drawback to this solution:
-In case of a reserve key compromise, coins generated by withdraw operation
(not refreshed ones) can be linked to withdraw operations, thus revealing
relationships between reserves and payments.
-This is because an adversary (exchange or auditor) in possession of a reserve
private key and coin public keys can calculate $ \text{H(Ed25519.Sign}(w_s,
C_p)) $ and check in the database if there is a corresponding withdraw
operation, thus linking reserve and coin.
-
-\subsubsection{Discussion}
-This is not perfect solution.
-It is designed to make untaxed payments using the withdraw loophole less
attractive to use for merchants.
-If accepted, it should only be used in deployments where the withdraw loophole
has to be prohibited.\\
-The proposed modifications achieve that a malicious merchant, who wants to
perform payments using the withdraw loophole, has to accept one of these
drawbacks:
-\begin{itemize}
- \item He has to accept that the customer is able to revert the payment.
- \item He has to spend the coins fully.\\
- If he is registered as a merchant at an exchange, he can perform payments
to himself to launder the money.
- Here, Talers \ac{AML} capabilities come into play.\\
- The other possibility is to buy goods at other merchants.
- These goods then have to be liquidated, which requires effort.
- This wouldn't be a problem (for the malicous merchant) if cryptocurrency
can be bought using Taler.
- \item He has to spend the coins partially to be able to refresh them (thus
preventing payment reversion by the customer).
- The goods that were bought using the coin fraction then would have to be
liquidated (see previous point).
- \item He has to add the threshold value that is lost in order to refresh
the coin into the price for payments.
-\end{itemize}
-
-The commitment added to the withdrawal weakens the privacy of coins.
-Blinding guarantees everlasting privacy, which would be neutralized by the
commitment.
-
-The added cut-and-choose makes withdrawing more intensive, which leads to
increased infrastructure requirements (and therefore costs).
-
-The added threshold makes coin spending less flexible.
-Wallets either have to contain more coins to guarantee that there is always a
coin (or multiple) available to guarantee a payment without violating the
threshold limitations.
-The other variant is that wallets refrain from withdrawing coins with big(ger)
denominations, which leads to bigger sums of coins used per payment.
-
-This discussed solution is submitted to the Taler team as a part of the thesis
documentation, upon which they can review the protocol changes and decide
whether to pursue further.
-Therefore, the solution will not be implemented during this thesis.
diff --git a/doc/cs/thesis.tex b/doc/cs/thesis.tex
index 1e4bfb87..b6abb0d7 100644
--- a/doc/cs/thesis.tex
+++ b/doc/cs/thesis.tex
@@ -56,7 +56,7 @@
%------------ Eidesstattliche Erklärung
-\includepdf[pages=1]{ads/Erklaerung}
+% \includepdf[pages=1]{ads/Erklaerung}
%------------ History
% \input{ads/history}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-exchange] branch master updated: implement feedback in cs thesis,
gnunet <=